RFC: Flavors - naming significant sets of customizations

RFC: Flavors - naming significant sets of customizations

[ian.tegebo]

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.  The first term that came to mind was "flavor", as it seems to largely be a matter of taste.

I've written up a few thoughts and linked to what I could find:

http://www.emacswiki.org/emacs/IanTegebo/Flavors

The above boils down to, "If it's a good idea, how do we do it?".

Comments appreciated,
-- 
Ian Tegebo

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

"ian.tegebo" <ian.tegebo@gmail.com> writes:

>  I've noticed a number of efforts to significantly customize Emacs in
> a way that other people can readily use.

First rule of Emacs:    Don't customize it :-)

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> First rule of Emacs:    Don't customize it :-)

That goes against the grain of what Emacs is, and is for, that I cannot
even begin to comment on it.  Fortunately, the smiley stopped me from
jumping out the window, at least for the time being.

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

>> First rule of Emacs:    Don't customize it :-)
>
> That goes against the grain of what Emacs is, and is for, that I
> cannot even begin to comment on it.

Just because Emacs allows customization doesn't mean that it ought to be
customized upfront.

1. Emacs is usable without or with just minimal customization.

2. Let customization appear naturally and in an effort-less way.  Let it
   grow.

3. I will not allow my neighbour to tell me how I arrange my furniture
   in my house.

Jambu's First rule of Emacs: Don't customize it.

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> >> First rule of Emacs:    Don't customize it :-)
> >
> > That goes [so much] against the grain of what Emacs is, and is for,
> > that I cannot even begin to comment on it.
> 
> Just because Emacs allows customization doesn't mean that it ought to be
> customized upfront.

Just because Emacs is designed, explicitly, to be The Customizable Editor
does not mean that one ought not to customize it, up front or down back
or out sideways.

> 1. Emacs is usable without or with just minimal customization.

Well of course.  Goes without saying.

> 2. Let customization appear naturally and in an effort-less way.
> Let it grow.

Who would argue otherwise?  Who would say that customization should
be hard to do or unnatural?

> 3. I will not allow my neighbour to tell me how I arrange my
> furniture in my house.

Did one of your neighbors try to tell you how to arrange your house?
Don't stand for that.

Your furniture.  Your house.  (Tsk, tsk.  My, my, my.)

> Jambu's First rule of Emacs: Don't customize it.

That's your first customization choice ;-): preferring the default
settings.  Nothing wrong with that.  To each her own.

But did you intend that as a `First Rule of Emacs' for others too?
Including your neighbors? ;-)

Re: RFC: Flavors - naming significant sets of customizations

[Stefan Monnier]

> Has anyone already come up with a name for large customizations?

"Theme"?

Current customization themes typically only customize faces, but the
underlying implementation allows a lot more flexibility since it can
customize any Custom var and can include Elisp code.


        Stefan

Re: RFC: Flavors - naming significant sets of customizations

[Dirk-Jan C. Binnema]

On Monday Nov 25 2013, monnier@iro.umontreal.ca wrote:

>> Has anyone already come up with a name for large customizations?
>
> "Theme"?
>
> Current customization themes typically only customize faces, but the
> underlying implementation allows a lot more flexibility since it can
> customize any Custom var and can include Elisp code.

They actually work quite well for that.

However, themes are not very 'hygienic' -- you cannot easily roll back a
whole theme; when you choose a new theme, it works on top of the already
chosen theme, with all the non-overridden settings still active.

--Dir.



-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Dirk-Jan C. Binnema <djcb@djcbsoftware.nl> writes:

> when you choose a new theme, it works on top of the already chosen
> theme, with all the non-overridden settings still active.

I find it annoying.  I wonder why such a choice was made?

Re: RFC: Flavors - naming significant sets of customizations

[Stefan Monnier]

> However, themes are not very 'hygienic' -- you cannot easily roll back a
> whole theme; when you choose a new theme, it works on top of the already
> chosen theme, with all the non-overridden settings still active.

Maybe I don't understand, but it sounds like a bug.
Or maybe a mis-use: custom themes *can* be stacked, so if you want to
replace a previous theme with a new one, then you need to remove the old
and add the new one.  Maybe the UI needs some work to make it more clear
(and make it easier to switch between themes).


        Stefan "who never used it"

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> > However, themes are not very 'hygienic' -- you cannot easily roll back a
> > whole theme; when you choose a new theme, it works on top of the already
> > chosen theme, with all the non-overridden settings still active.
> 
> Maybe I don't understand, but it sounds like a bug.

It is.  Bug ##15687:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687

> Or maybe a mis-use: custom themes *can* be stacked, so if you want to
> replace a previous theme with a new one, then you need to remove the old
> and add the new one.  Maybe the UI needs some work to make it more clear
> (and make it easier to switch between themes).

The bug is not the fact that you can accumulate the effects of multiple
custom themes.  The bug is the fact that you cannot restore the state of
Emacs before any theme was applied.  There is no way to take a snapshot
of Emacs before theming and then restore to that.

You can add themes, for a cumulative effect, or you can replace the use
of one theme by another, but you cannot undo a theme, i.e., you cannot
untheme.

Such undoing was, and still is, trivial to accomplish with color themes:
http://www.nongnu.org/color-theme/.

This is the main reason that it is wrong to think of Emacs custom themes
as replacing color themes or, as is commonly stated, the former make the
latter obsolete.  So far, each has some advantages over the other.

Re: RFC: Flavors - naming significant sets of customizations

[William G. Gardella]

Drew Adams <drew.adams@oracle.com> writes:

>> > However, themes are not very 'hygienic' -- you cannot easily roll back a
>> > whole theme; when you choose a new theme, it works on top of the already
>> > chosen theme, with all the non-overridden settings still active.
>> 
>> Maybe I don't understand, but it sounds like a bug.
>
> It is.  Bug ##15687:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687
>
>> Or maybe a mis-use: custom themes *can* be stacked, so if you want to
>> replace a previous theme with a new one, then you need to remove the old
>> and add the new one.  Maybe the UI needs some work to make it more clear
>> (and make it easier to switch between themes).
>
> The bug is not the fact that you can accumulate the effects of multiple
> custom themes.  The bug is the fact that you cannot restore the state of
> Emacs before any theme was applied.  There is no way to take a snapshot
> of Emacs before theming and then restore to that.

Actually, there is: (disable-theme 'foo-theme), or globally,
(mapcar 'disable-theme 'custom-enabled-themes).  This functionality is
also already exposed by the M-x customize-themes GUI, which defaults to
disabling enabled themes for enabling a new one.

The "bug", if there is one, is simply that the UI doesn't expose this
nicely (in fact, doesn't expose it nicely for experienced users such as
yourself to notice it).

Re: RFC: Flavors - naming significant sets of customizations

[William G. Gardella]

"William G. Gardella" <wgg2@member.fsf.org> writes:

> Actually, there is: (disable-theme 'foo-theme), or globally,
> (mapcar 'disable-theme 'custom-enabled-themes).  This functionality is
> also already exposed by the M-x customize-themes GUI, which defaults to
> disabling enabled themes for enabling a new one.

  s/"for enabling"/"before enabling"/

> The "bug", if there is one, is simply that the UI doesn't expose this
> nicely (in fact, doesn't expose it nicely for experienced users such as
> yourself to notice it).

  s/"nicely for"/"nicely enough for"/

Posted in haste, my apologies.

-WGG

Re: RFC: Flavors - naming significant sets of customizations

[William G. Gardella]

"William G. Gardella" <wgg2@member.fsf.org> writes:

> "William G. Gardella" <wgg2@member.fsf.org> writes:
>
>> Actually, there is: (disable-theme 'foo-theme), or globally,
>> (mapcar 'disable-theme 'custom-enabled-themes).  This functionality is
>> also already exposed by the M-x customize-themes GUI, which defaults to
>> disabling enabled themes for enabling a new one.
>
>   s/"for enabling"/"before enabling"/

Ugh, I mean (mapcar 'disable-theme custom-enabled-themes).  Still posted
in haste, apparently. :-/

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

"William G. Gardella" <wgg2@member.fsf.org> writes:

> Ugh, I mean (mapcar 'disable-theme
> custom-enabled-themes)

Aha, so that word ("theme") is already in Emacs!
Deeming from the help, a theme is a variable and face
settings state.

I guess "variable" means keymaps as well?

Including keys in the word "theme" is stretching it a
bit, because I take it the themes will be named like
the Openbox themes (like "day", "fog-mine", etc.),
i.e., based on what they look like, and not on finger
habits. I configured the Dired keys and the Gnus keys
to coincide, so I guess that's a "theme" as well, and
I'll call it "ijkl"... But this example shows that it
is just not an intuitive use of the word. I mean, how
many other such "themes" can you think of?

Is there a need for *one* word for this? To me,
intuitively:

1. If you disable the scrollbar or set the foreground
   face, that's customize.
2. If you rebind the keymaps and change the parameters for
   scrolling, filling, etc., that is configuration.
3. If you write wrapper functions and aliases, that is
   tuning and streamlining the interface
   (personalization, perhaps).
4. If you write Elisp that does something that's not in
   Emacs at all, that extension.

For it to be a "theme", the changes must hook into each
other in a way that emphasizes some common factor. For
1, you can have a bright-on-black theme, a non-GUI
theme, a minimalist theme, and so on. But for 2-4 I can
only describe my thought how I think it should be, and
nothing more, so either I'm narrow-minded or the
concept theme just does not apply beyond the
superficial level.

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

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> > The bug is not the fact that you can accumulate the effects of multiple
> > custom themes.  The bug is the fact that you cannot restore the state of
> > Emacs before any theme was applied.  There is no way to take a snapshot
> > of Emacs before theming and then restore to that.
> 
> Actually, there is: (disable-theme 'foo-theme), or globally,
> (mapcar 'disable-theme 'custom-enabled-themes).  This functionality is
> also already exposed by the M-x customize-themes GUI, which defaults to
> disabling enabled themes for enabling a new one.
> 
> The "bug", if there is one, is simply that the UI doesn't expose this
> nicely (in fact, doesn't expose it nicely for experienced users such as
> yourself to notice it).

What makes you think I didn't notice it?  Why don't you please read the
bug report?

The point is that "disabling" a custom theme only disables it relative
to other themes.  It does not *undo* the application of the theme.  It
does not restore Emacs to the state before applying the theme, even
approximately.

If you start with a customized Emacs (faces, variables, frame
parameters, whatever) and then apply a custom theme, you have no prayer
of returning to what things were like before applying the theme.

That's the point.  With color themes there is no such problem.  There
is a pseudo-theme ([Reset]) for restoring the state before theming.
It does not guarantee to restore absolutely everything, but it does a
pretty good job of things.

This important feature of color themes is missing from custom themes
(AFAICT).  You cannot take a snapshot of the Emacs state before
applying a custom theme, and then restore that snapshot state after
applying the theme.  With color themes this is trivial to do (and
fast) - the snapshot is treated more or less as a theme (call it a
pseudo-theme).

---

The other problem with custom themes (compared to color themes) is
that they are extremely slow if you have multiple frames open.

And this is the case even if you inhibit the accumulation of
themes, so that instead of each theme applied building on top of
the previous ones it just replaces the last one (so only one theme
is used at a time).

If you allow accumulation (the default behavior) then Emacs just
grinds to a halt.  Switching among color themes is super fast, no
matter how many frames there are.

Don't get me wrong - I'm glad we have custom themes.  The point
is only that, so far, they are not a sufficient *replacement* for
color themes.  Each has its advantages, so far.  Unfortunately.

Currently, if you are mainly interested in colors (e.g., faces &
frame parameters) then color-theme.el is still the way to go,
AFAICS.  If you are mainly interested in variables, then probably
custom themes are more useful.

Re: RFC: Flavors - naming significant sets of customizations

[Stefan Monnier]

> of one theme by another, but you cannot undo a theme, i.e., you cannot
> untheme.

Hmm... doesn't ring a bell.  Do we have a bug number for that?


        Stefan

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> > of one theme by another, but you cannot undo a theme, i.e., you cannot
> > untheme.
> 
> Hmm... doesn't ring a bell.  Do we have a bug number for that?

Yes.  Look further up in the same mail you quoted from.  It says this:

  Bug ##15687:
  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687

RE: RFC: Flavors - naming significant sets of customizations

[Drew Adams]

> However, themes are not very 'hygienic' -- you cannot easily roll back a
> whole theme; when you choose a new theme, it works on top of the already
> chosen theme, with all the non-overridden settings still active.

Actually, you could, with the _color_ themes that inspired Emacs's
_custom_ themes.  See Emacs bug #15687:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15687

This was one thing that Emacs did not get right wrt themes - a major failing.
So far, at least.

Re: RFC: Flavors - naming significant sets of customizations

[ian.tegebo]

On Monday, November 25, 2013 11:54:09 AM UTC-8, Stefan Monnier wrote:
> > Has anyone already come up with a name for large customizations?
> 
> "Theme"?
> 
> Current customization themes typically only customize faces, but the
> underlying implementation allows a lot more flexibility since it can
> customize any Custom var and can include Elisp code.

Ah, thanks Stefan.  I'd learned about themes long enough ago that I'd thought of them only as color themes.  I'll update my wiki page.

-- 
Ian Tegebo

Re: RFC: Flavors - naming significant sets of customizations

[Ted Zlatanov]

On Mon, 25 Nov 2013 14:54:09 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Has anyone already come up with a name for large customizations?
SM> "Theme"?

SM> Current customization themes typically only customize faces, but the
SM> underlying implementation allows a lot more flexibility since it can
SM> customize any Custom var and can include Elisp code.

Seconded, it's the most natural name and the functionality is there.

But there's a wider issue of "how do I structure my .emacs" that
everyone seems to solve differently[1], and which I would argue is a
form of customization.

Ted

[1] yes, [insert method here] is indisputably the best one.  If only
everyone switched to [insert method here]!

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Ted Zlatanov <tzz@lifelogs.com> writes:

> But there's a wider issue of "how do I structure my
> .emacs" that everyone seems to solve differently[1],
> and which I would argue is a form of customization.

From a technical standpoint, it makes sense to have
small bundles of configurations, all well defined. Then
they would have priority so that you could stack them
so there's no conflicts (or mutex "fields" where they
apply, perhaps).

But from a human standpoint, it sounds too much like
the total fragmentation of the Linux distributions,
that is counter-productive and downright bizarre.

In "Linux Magazine" there are seasoned old
professionals who reason like this:

newbie: what Linux distribution should I choose?
pro: there is no right or wrong. test a couple and
     determine what suits you the best.

This is *dead wrong*. The right answer is "it doesn't
matter. just pick *any* with a history, a reputation,
and an active user base. whatever you then stumble upon
that you don't like, you can change in 1 second,
because in 99% of the cases, such problems will not
relate to either the kernel or the distribution, but to
the *software*, which always is the same, and not only
across the Linux world but over the entire scope of
Unix, Solaris, BSD, you name it."

The same sort of fragmentation and rebranding of Emacs
is something I never want to see. The attitude that
should be encouraged is: "if you have a problem, you
can fix that problem, by fixing that problem, and that
problem alone. and you don't need to install or
download anything to do that."

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

Re: RFC: Flavors - naming significant sets of customizations

[Peter Dyballa]

Am 25.11.2013 um 20:31 schrieb ian.tegebo:

> Has anyone already come up with a name for large customizations?

Skin? (Virtual) Personality (vip)?

"Karakter" is a very good Dutch film. Black & white.


Classic Mac OS had a "Gestalt" – (a good) shape, form, figure, …

--
Greetings

  Pete

Some day we may discover how to make magnets that can point in any direction.

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

"ian.tegebo" <ian.tegebo@gmail.com> writes:

> Has anyone already come up with a name for large customizations?

facade, persona, veneer, motif, genre

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

> 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.  The first term that came to
> mind was "flavor", as it seems to largely be a matter
> of taste.

It can be a matter of taste but it can also be a matter
of necessity. At a "middle level" it can be a matter of
severely increasing your productivity. At an "attitude
level" it is about being serious about one of the most
important things in all activity: the human-tool
coordination and interaction ("interface", I guess, but
a dynamic one).

"Theme" and "skin" do it an injustice, as at least my
associations of those words is that it is a matter of
"look and feel" only. Remember the winamp mp3 player?
It had skins (or "skinz", x0 x0). Java applications
have themes: if you juggle with the
jar-files/classpath, extract the main class, download
the themes (often many, as they inherit from each
other), set the look and feel option - and then, you
are almost done! Customizing and programming Emacs is
on a whole other level. I don't want to be associated
with that kind of lunacy.

That Emacs in general should not be customized/extended
is *radical*, this is the property of Emacs that is
always emphasized, and people always say "I wish it was
like in Emacs" when they use other applications and
stumble upon something they don't like: "... then I
could just fix it instantly!"

However, you should not get stuck in it. But if you do,
it is not the worst place to get stuck in. Every
minimal change I do to Emacs is something I immediately
benefit from, no matter how little. Compare this to all
guys who get stuck in their "MMORPG" projects that will
never be done anyway, and from which whatever knowledge
that is nevertheless gained is very difficult to apply
anywhere else.

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

Re: RFC: Flavors - naming significant sets of customizations

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

() "ian.tegebo" <ian.tegebo@gmail.com>
() Mon, 25 Nov 2013 11:31:46 -0800 (PST)

   Has anyone already come up with a name for large customizations?

I maintain ttn-pers-elisp, last released 2008, but churning locally w/
high frequency.  Here are some names i've called it (and the class of
software it embodies):

stance
tude (attitude)
mood
residual-self-image :-D
moment
mindset
malarky
bosh
folly
voodoo
grunge
grot
grooviness
lump
frosting
futzing
playpen
decades-long-maintenance-burden
yoke
fardello
parachute
writ-wrap
meaning
personal-coping-mechanisms
yada-yada
soot

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: RFC: Flavors - naming significant sets of customizations

[Peter Dyballa]

Am 25.11.2013 um 20:31 schrieb ian.tegebo:

> 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.  The first term that came to mind was "flavor", as it seems to largely be a matter of taste.

On second thoughts I think that "romper suit" could be a splendid choice.


There are voices that call GNU Emacs being old. (Ridiculous!)

All the time missing documentation is detected. (Comes from hiding private parts in public.)

Particularly in German "romper suit" (meaning a suit to struggle or kick about) has a hidden connotation: It seems to motivate younger ones to try to escape it… (There exists a similar and clean white suit for a particular sort of residents. And might be possible that some customisation escapes that "large customization".)

It adds to the use of GNU Emacs specific terms. (Frame, window, buffer, mode line, point, …)

--
Greetings

  Pete

We have to expect it, otherwise we would be surprised.

Re: RFC: Flavors - naming significant sets of customizations

[Stefan Monnier]

> It adds to the use of GNU Emacs specific terms. (Frame, window,
> buffer, mode line, point, …)

That'd be nice, indeed.  But better would be to use a term that is
already used widely outside of Emacs (but with a different meaning,
obviously).

E.g. we could call a set of customizations a "short-cut".


        Stefan

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> I maintain ttn-pers-elisp, last released 2008, but
> churning locally w/ high frequency.  Here are some
> names i've called it (and the class of software it
> embodies):

After a webgrep, I found

http://www.gnuvola.org/software/personal-elisp/

but the topmost hits are 404, like

http://www.glug.org/people/ttn/software/

The page that works seems to be version 1.59 from 2008,
so that is the "last release". But that was five years
ago...

Without comparing our projects, because I have yet to
open the first .el file, what I do is, I just have
symbolic links in a directory called "conf", then an
alias to copy them to a remote (safe, I hope)
location. I setup this to have a fast backup command,
and not to "release" stuff, but I don't see a conflict
in that. (That folder is very useful as an "index" of
configuration, as well.) Just a thought...

Anyway, this will be very interesting. It all looks
very professional. But what I immediately looked for
and didn't find was a file like PURPOSE. Perhaps
tomorrow I'll write such a short file describing my own
project.

After one million jokes and poems, I am not the
slightest surprised to find this super-ambitious
project.

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

Re: RFC: Flavors - naming significant sets of customizations

[Rustom Mody]

On Tuesday, November 26, 2013 1:01:46 AM UTC+5:30, ian.tegebo wrote:
> 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.  The first term that came to mind was "flavor", as it seems to largely be a matter of taste.
>
> I've written up a few thoughts and linked to what I could find:
>
> http://www.emacswiki.org/emacs/IanTegebo/Flavors
>
> The above boils down to, "If it's a good idea, how do we do it?".
>
> Comments appreciated,

I remember Alan Mackenzie use the word 'emacsicality'.

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

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

Re: RFC: Flavors - naming significant sets of customizations

[Rustom Mody]

On Friday, November 29, 2013 9:54:36 AM UTC+5:30, Emanuel Berg
wrote:
> Rustom Mody  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. 

Standard (and contentious) example: cua.

Current cua-mode is a hack.
If someone wants cua *keybindings* with standard emacs *functionality*
he is out of luck because this requires deep surgery on all modes -- moving
out C-x and C-c to some other keys.

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Rustom Mody writes:

>> I still don't understand what a "large
>> customization" is, or is supposed to be.
>
> Standard (and contentious) example: cua.
>
> Current cua-mode is a hack.  If someone wants cua
> *keybindings* with standard emacs *functionality* he is
> out of luck because this requires deep surgery on all
> modes -- moving out C-x and C-c to some other keys.

So what are you saying, someone would perform that deep
surgery (to get a non-hack cua), and this would be an
Emacs "suite"?

That doesn't really synch with those examples
Jambunathan K provided. Those actually sound exactly
like the Linux distros: repackage the same thing (over
and over again) based on the different behaviour of the
(segmented) user base.

Let me give you an actual example, and you tell me if
this is a good idea.

In the current issue of "Linux Magazine" (a magazine
that, by the way, dropped their entire "letters"
section the moment I started writing to them), anyway
in that issue there is a review of the latest "new"
Linux distro: openArtist.

openArtist is based on Ubuntu. (They didn't mention
that Ubuntu, in turn, is a Debian derivative.) The
reviewer noted the following.

* openArtist uses GNOME 3 as the desktop suite, only,
  it is in the "GNOME 2 mode".
* The desktop has a black-and-gray color theme. (!)
* Contrary to the Ubuntu philosophy (one tool per area
  of computer activity), openArtist provides lots of
  tools for various purposes within the artistic field.

And so the reviewer notes: as there are so many tools
provided, openArtist is probably most likely to attract
"advanced users".

I mean: Completely and utterly *outrageous*! I whole
f-ing distro just to make GNOME 3 look like GNOME 2, to
set the background to black, and to install various
tools - installing, a *one-liner* with aptitude! And
after that, they dare say this is something for
"advanced users"!

And then just think of all the superstructure work that
has to be done managing a distro - homepage, mailing
lists, policy decisions, etc. etc. (And if you think
I'm exaggerating, just pick up the magazine at your
local public library and read it for yourself.)

Can anyone tell me why we should do this for Emacs?

We should do *new* things (or *improve* things), and
not rebrand, repackage, etc. what is already here!

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> So what are you saying, someone would perform that deep
> surgery (to get a non-hack cua), and this would be an
> Emacs "suite"?

Let me give you some historical perspective.

Story of Orgmode
===============

I will give you an example of Org-mode.  It started out as a simple
library - outline-magic.el.  The author - Carsten Dominik - was happy
with outline.el but unhappy with the default keybindings.

He wrote outline-magic.el and instead of keeping it in his hard disk or
putting on github he kept improving it and evolving it.

Orgmode became a monster.

Orgmode became useful but since it was an evolved software - (i.e, a war
veteran, having memory of what works or what didn't, what is needed and
what not) - it had it's limitations.  It was like my Grandma's house
having memories of her times, her children't times and her
grandchildren's times.

So, Nicolas Goaziou comes in and builds upon existing knowledge and
experiences, canonicalizes the syntax and makes the exporters robust.
Now this work is unlike what Carsten or earlier people did.

It is an upfront design or with little or minor deviations from start to
finish.

So, the original Orgmode which was started out as an evening walk turned
in to a pleasant jog and occasionally became a fartlek (with a mix of
intensive workouts interspersed with plain walk)

The later effort is like a competititve marathon - intensive in both
spatial and temporal sense.

The Software Engineering Books call this Iterative Development and
Waterfall models.

----------------------------------------------------------------

Story of Emacswiki (as told by Jambunathan)
===========================================

Unlike Orgmode, the Emacswiki effort is like a pleasant long walk from
southern pole to the northern pole.  No purpose.

It is a waterfall, nevertheless.  "Community Effort" and "No Control"
was right there when it started and continues to this day (even after a
decay).

The waterfall here is not a Niagara but a Bridal Veil.

----------------------------------------------------------------

> That doesn't really synch with those examples
> Jambunathan K provided. Those actually sound exactly
> like the Linux distros: repackage the same thing (over
> and over again) based on the different behaviour of the
> (segmented) user base.

If one cannot bring in intensity one can atleast bring in patience and
perseverance.  One no valuable than the other.

People who have a sense of history - those who have seen a oak tree - in
a frivolous seed - add water and remove weeds and more importantly
refrain from uprooting the seed out of the soil.

So, try it out or just note it in diary.  Someone who proposes may be
weak heart and may never start out his journey if he finds no
encouragement.

----------------------------------------------------------------

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> It is a waterfall, nevertheless.  "Community Effort" and "No Control"
> was right there when it started and continues to this day (even after a
> decay).
  ^^^^^
I meant decade.  

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Story of Orgmode
> ===============

Story of Elisp manual
====================

Another interesting story is that of the Elisp manual.  It was initially
the work NOT of Richard but couple of students.

The students packed enough punch in to their original work that it was
bundled with Emacs and to this day the manual continues improving.

1. Pack enough punch, when starting out.
2. Keep a gentle pressure, as the time progresses.

(1) and (2) are in no specfic order.

----------------------------------------------------------------

Here it is:

URL:
https://groups.google.com/forum/#!msg/comp.lang.lisp/9wmmzyPrtwc/pXcOQ8Ll5LcJ

Mailing list: comp.lang.lisp
Poster: "Xah Lee"
Date: 20/06/2008
Post titled: history of the GNU Emacs Lisp Reference Manual

The above URL will die in another 5 or 10 years.  I am unable to locate
text archives.  Here is the relevant text.  Start from end of buffer.

----------------------------------------------------------------
Xah Lee writes:

does anyone know the history about who are the main persons that wrote
the GNU Emacs Lisp Reference Manual?

According to the manual itself:

http://xahlee.org/elisp/Acknowledgements.html

quote:

«This manual was written by Robert Krawitz, Bil Lewis, Dan LaLiberte,
Richard M. Stallman and Chris Welty, the volunteers of the GNU manual
group, in an effort extending over several years. Robert J. Chassell
helped to review and edit the manual, with the support of the Defense
Advanced Research Projects Agency, ARPA Order 6082, arranged by Warren
A. Hunt, Jr. of Computational Logic, Inc.»

So, the first author listed are Robert Krawitz and others. Richard
Stallman didn't come until after 3 names.

Does anyone have some history or reference as to how the manual came
together or better picture of who are the main authors?

By publishing convention, if i were just to write “written by xyz et
al.”, that would be Robert Krawitz. But as far as i know the first few
persons listed are little known... anyone got detail?

----------------------------------------------------------------
Tim Bradshaw writes:

I suspect that the acknowledgements are correct.  For a long time there
was no elisp reference manual at all - there was an emacs manual and
there were docstrings but that was it.  Certainly this was true in the
Emacs 17 timeframe.  I have some vague memory that there was a period
when there was an elisp manual you could get from some different source
than emacs, written by, I suppose, these people, but then it got merged.

----------------------------------------------------------------

John Thingstad writes:

From emacs 18 on at least there was a elisp manual. But you had to
download it seperatly.  (I only started with emacs in 1987)

----------------------------------------------------------------
Bob Knighten writes:
    
Even though I get acknowledged in the manual, my contribution was 20
years ago and my memory is fading.  But there is a little bit of
information at http://www.gnu.org/bulletings/bull4.html which says:
"Thanks to Dan LaLiberte for spearheading the GNU Emacs Lisp Programmers
Manual, and to Bill Lewis and Tom Scott who have been working on putting
it all together."

You can read a little bit about Dan LaLiberte's contribution (as a
graduate student at University of Illinois - Urbana Champagne) at his
web page: http://www.hypernews.org/~liberte/ and I expect he will be
happy to tell you more.

I remember exchanging e-mail with him and also recall Bil Lewis
(http://www.lambdacs.com/bil/bil.html) being involved, but I don't
recall Tom Scott and notice that his name disappeared by the time the
manual was actually published.  I think that Krawitz and Welty are
relatively recent additions to the team and that neither LaLiberte nor
Lewis are currently active.  My recollection was that as on pretty much
all parts of GNU Emacs Stallman's role on the Emacs Lisp manual was as
original creator, godfather and critic of all things Emacs.

----------------------------------------------------------------
Xah Lee writes:

I've added few more links i found to home pages of some of the other
major contributors.  http://xahlee.org/emacs/day_one.html

----------------------------------------------------------------

Daniel LaLiberte writes:

Thanks to Dan Weinreb for pointing me at this recent exchange.   You
guys have done a fine job of digging up this ancient history, but I am
glad to offer any more tidbits I can recall.

Starting with Emacs 17, and transitioning to Emacs 18, I was trying to
develop a rather substantial extension and I was forced to learn what I
could from the very limited doc strings, and the source itself.  I
started putting together a document for my own use of all the functions,
variables, etc, and at some point started sharing this with others.  I
didn't think I had time to really finish this documentation, but I
recall announcing my offer to coordinate the efforts of others if they
would help out.

With a group of about a dozen volunteers, we hobbled along for a year or
so, and then we learned that Bil Lewis had offered to write up a first
draft of the entire manual, which he then did in cooperation with our
group.  I received his work as it was being written and edited it,
reorganizing the material substantially over the next year or two.  My
graduate research work was delayed as a result, but I was having fun,
getting into it and receiving the reward of compliments from grateful
readers.  I'd have to say that most of the first year of work was
overwritten a couple times by this process, so we probably dropped some
of the minor acknowledgments as well.

Although I had a major hand in every chapter, the one on the Edebug
source-level debugger was all mine, of course, since I had written the
software.  Having mastered everything about the language and
environment, it became obvious to me in a flash how to build Edebug, and
the first version was hacked out in a couple weeks.  This little
diversion turned into a major project, and a new subject for my masters
research.

Shortly before Emacs 19 started to come out, I was finishing up the
indexing (including a very useful permuted index) and we were "done" and
then RMS wanted to take control.  After a few more months of his
reediting, cleaning up all my rampant use of passive voice and such, it
was published in a two-volume book.  Later editions by RMS and others
incorporated the Emacs 19 features.  I got back into my research and
lost touch.

Since the web grabbed my attention around 1994, I haven't done much of
anything with Emacs, except I continue to be a reluctant user, stuck
with emacs bindings to my brain, frustrated by its archaic UI as the
world moves on.  Now JavaScript is my favorite language, and the web
browser would be the environment in which one might do everything,
except we are not quite there yet.

----------------------------------------------------------------

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> Since the web grabbed my attention around 1994, I
> haven't done much of anything with Emacs, except I
> continue to be a reluctant user, stuck with Emacs
> bindings to my brain, frustrated by its archaic UI as
> the world moves on.  Now JavaScript is my favorite
> language, and the web browser would be the
> environment in which one might do everything, except
> we are not quite there yet.

Unbelievable! (?! - I'm chocked!)

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> So, the original Orgmode which was started out as an
> evening walk turned in to a pleasant jog and
> occasionally became a fartlek (with a mix of
> intensive workouts interspersed with plain walk)

Ha ha, so you know about that. "Fartlek" is Swedish:
fart = speed, and lek = game (or "play" perhaps).

> People who have a sense of history - those who have
> seen a oak tree - in a frivolous seed - add water and
> remove weeds and more importantly refrain from
> uprooting the seed out of the soil.

Absolutely, that's correct.

> So, try it out or just note it in diary.  Someone who
> proposes may be weak heart and may never start out
> his journey if he finds no encouragement.

Yeah, but in your reasoning and those examples, I don't
see how that applies because I'm not opposed to such
projects. I'm opposed to the projects like openArtist,
which a described, but what I can see that project is
*the opposite* of the projects you describe (new stuff:
Org-mode, EmacsWiki, and the Elisp manual).

But I enjoyed reading that, so thanks.

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> So what are you saying, someone would perform that
> deep surgery (to get a non-hack cua), and this would
> be an Emacs "suite"?

No, it is the other way around, of course!

Aha! Then the analogy with the Linux distributions is -
well, in many ways, it *is* the same, but purely
practical, to us, it is just a couple of configuration
files. And those are already done, at most we need to
compile them. We don't need any CDs/DVDs, homepages,
listbots, T-shirts ... One .el file will make a huge
difference, compared to a huge distro that changes the
background.

This could actually be the *opposite* to reinventing
the wheel because if there are those suite files
available, people don't have to do that configuration
themselves.

OK, I change my mind. It is a good idea.

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> ...because if there are those suite files available, people don't have
> to do that configuration themselves.

It is not just the question of availability.  It should be available in
a centralized place and that it should be improved upon.

Merely having a "common" customization shared in a centralized place
like Gnu Emacs or Gnu Elpa is a great way to build consensus or build on
(or atleast learn from) each other efforts.

Do you know of GNU ELPA?

    http://elpa.gnu.org

Have you done?

   M-x list-packages

May be you want to share some of your Emacs customization in these
places....

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> practical

Practical cannot be dismissed.

Consider two scenarios:

1. Emacs available as a binary (pre-installed or installable in your
   favorite distribution).

2. Emacs should be built from scratch.

If you are an average newcomer - say from Philosophy dept. - what will
you do?

I was introduced to Org-mode only because it was part of Emacs.  So...

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> ...because if there are those suite files available,
>> people don't have to do that configuration
>> themselves.
>
> It is not just the question of availability.  It should
> be available in a centralized place and that it should
> be improved upon.
>
> Merely having a "common" customization shared in a
> centralized place like Gnu Emacs or Gnu Elpa is a
> great way to build consensus or build on (or atleast
> learn from) each other efforts.

Yes, availability and quality and "focal point" of
efforts.

> May be you want to share some of your Emacs
> customization in these places

Yes, I will go through my Elisp and for each defun, ask
myself if it is something I did just because I like it
that way or if it is something others could benefit
from. I think most of it isn't, but I know some is, so
I will do it. When I'm done, should I post it on
gnu.emacs.sources and then someone will decide if it
is? I'm fine with that method and I don't think
discussion will be needed: I did this for myself and I
will continue to use it, so there is no potential loss
(on my part at least :)).

By the way, I configured Gnus to show a short comment
for each group and for gnu.emacs.sources it says "Lisp
and C only" (pseudo-quote) emphatically - is this a
remnant of some glorious past? Because I don't see lots
of people spamming the group with Perl and C++...

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> Yes, I will go through my Elisp and for each defun, ask myself if it
> is something I did just because I like it that way or if it is
> something others could benefit from. I think most of it isn't, but I
> know some is, so I will do it.

Strange.  I went through precisely the same thoughts when I wrote the
first ever library I wanted to share.

So "merely" shifting your POV from "a user" to "a sharer" triggers a
different chain of thoughts.  Even if you don't share, this is a good
POV for it's own sake.

> When I'm done, should I post it on gnu.emacs.sources

Yes or You can say that you want to put it in GNU ELPA (if the library
is more useful).

You will get lots(?) of feedback from experienced lispers.  That is a
low traffic and high quality list, usually visited by folks who are
serious about Emacs Lisp and are not hesitant to have a conversation.

I think of mailing lists as dropbox (only that the dropbox is all over
the city) or as a pastebin.  I just "save" my little trick in the
mailing list and in a decade from now if I have to "retrieve" that
snippet all I have to do is search for my own posts.  The "side effect"
is that others can also hit upon it.

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> Yes, I will go through my Elisp and for each defun,
>> ask myself if it is something I did just because I
>> like it that way or if it is something others could
>> benefit from. I think most of it isn't, but I know
>> some is, so I will do it.
>
> Strange.  I went through precisely the same thoughts
> when I wrote the first ever library I wanted to
> share.

Yeah, but isn't that natural?

> So "merely" shifting your POV from "a user" to "a
> sharer" triggers a different chain of thoughts.  Even
> if you don't share, this is a good POV for it's own
> sake.

What? :) No, as for me, I always want all of my coding
public. I was once kicked out of my local Linux User
Group (a don't want to say which, because this might be
Googled and as for me, that's ancient history) because
almost every day I posted "odd material" (i.e., Linux
snippets and hacks) on their list :)

Actually, it is very sad. There is no one to talk to
except for Usenet. Where are all the programmers? They
are not doing what I'm doing, that's for sure.

>> When I'm done, should I post it on gnu.emacs.sources
>
> Yes or You can say that you want to put it in GNU
> ELPA (if the library is more useful).
>
> You will get lots(?) of feedback from experienced
> lispers.

Are you talking ELPA, or gnu.emacs.sources? Because I
posted my Emacs major mode "fpscalc" - small tool,
small revolution (compare Cuba) - but still an
undertaking, and I didn't get a single reply. On the
other hand, I got lots of help here, at gnu.emacs.help
- so perhaps there wasn't much to say?

As for now, I don't know how to access ELPA. I guess
that's in one of the links you gave earlier. Getting'
there.

> I think of mailing lists as dropbox (only that the
> dropbox is all over the city) or as a pastebin.  I
> just "save" my little trick in the mailing list and
> in a decade from now if I have to "retrieve" that
> snippet all I have to do is search for my own posts.
> The "side effect" is that others can also hit upon
> it.

Listbots are great! I wouldn't know jack without
them. I do exactly as you do for conversations (facts,
quotes, etc.) but for the code itself, I always keep on
my computer in their original files, as well as scp to
a remote location. I would rather loose all my physical
possessions than those system-wide configuration files.

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> What? :) No, as for me, I always want all of my
> coding public. I was once kicked out of my local
> Linux User Group (a don't want to say which, because
> this might be Googled and as for me, that's ancient
> history) because almost every day I posted "odd
> material" (i.e., Linux snippets and hacks) on their
> list :)

Oh... Telling that story reminded me of all the drama I
was in on *this* list (newsgroup). Let me tell you. It
takes two to tango. I have forgiven everyone including
myself. But I'm keeping you in my KILL file just the
same as a practical measure so it won't happen all
over.

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> Actually, it is very sad. There is no one to talk to
> except for Usenet. Where are all the programmers? They
> are not doing what I'm doing, that's for sure.

I thought you know about IRC chat.

There is lots of chat (sometimes animated chat) + gossip that goes in
the #emacs channel on irc.freenode.net.  Most of the conversation
happens during European time and US time.

So you may like to hang around there and ask what those folks are doing
there.

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> Actually, it is very sad. There is no one to talk to
>> except for Usenet. Where are all the programmers?
>> They are not doing what I'm doing, that's for sure.
>
> I thought you know about IRC chat.
>
> There is lots of chat (sometimes animated chat) +
> gossip that goes in the #emacs channel on
> irc.freenode.net.  Most of the conversation happens
> during European time and US time.
>
> So you may like to hang around there and ask what
> those folks are doing there.

Yes, I did some of that, and even put together a small
page on Irssi, with some Perl extensions [1]. And I did
find that Emacs channel, but there was only only one
guy there. But anyway, I don't like IRC. It disturbs my
workflow. To each his own. But if there are any really
cool discussions there, I guess you could post them
here.

[1] http://user.it.uu.se/~embe8573/irssi/index.html

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> But if there are any really cool discussions there, I guess you could
> post them here.

The discussions are not archived.

What I meants was IRC is a good place to gossip as long as the OPs are
on your sides.  Mailing lists like this are un-suitable for such
gossips.

More specifically, your (or my) stream-of-consciousness-style posts
doesn't suit this medium, the mailing list.

It is better to particular attention to the posts you - Emanuel - makes
on this list and make it not a stream but a still-pond.

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> But if there are any really cool discussions there,
>> I guess you could post them here.
>
> The discussions are not archived.

You can flush an IRC buffer to a file on your disk. I
don't remember how to do that, and I'm not going to
find out as I'm not into IRC, but it is a simple
built-in command, that much I remember.

> What I meants was IRC is a good place to gossip as
> long as the OPs are on your sides.

No, my experience is actually that IRC isn't a good
place at all. It is disruptive ("idle/busy wait" for
responses), and you can only type your messages in that
small typing area. Compare this to mails (and/or Usenet
posts) which make for much more well-thought (and
persistent) communication.

Also, people seem to have a bad attitude in general on
IRC. Lots of people there just idling, never saying a
word, setting up bots to look even more imposing. IRC
was fun as long as I configured Irssi but I never used
it for any good.

> Mailing lists like this are un-suitable for such
> gossips.

I'm not gossiping. That Linus Torvalds is rude to his
programmers in the Linux kernel community is a
well-known fact. This is not a piece of information I
have acquired in close-quarters and now release to the
world. You just need to join the LKML to experience
this first hand. This has also been mentioned several
times in the press the past half year or so.

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> practical
>
> Practical cannot be dismissed.

No, that's what made me turn around on this. I would
even be in favour of the plethora of Linux distros if
they were just a bunch of configuration files.

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

Re: RFC: Flavors - naming significant sets of customizations

[Yuri Khan]

On Fri, Nov 29, 2013 at 11:24 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> 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.

It just occurred to me that it’s not so much a “taste” or “flavor” as
a “topping”. Meaning, you can usually have just one of the available
flavors, but any subset of available toppings.

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

The OP has settled for "suits".

I think "Halloween" would be a good word.  Not only that it is funny, it
is also scary and also functional (During you assume a different
personality via masks and dresses etc.)

Emanuel Berg <embe8573@student.uu.se> writes:

> I still don't understand what a "large customization" is, or is
> supposed to be.

A good way to think would be to "segment" the users.

If one just puts a starting init file for each of the "segment" in GNU
ELPA, then this file and library itself will become a focal point for
consensus building.  In a word, the .el file becomes a "clearing house"
for common or recommended configuration.

0. Generic

   - Disable splash screen
   - Set user name
   - Set user mail address

0.5 - Dark theme users
    - Light theme users

1. Prose only folks.

   - Spell checking
   - Dictionary & Thesaurus
   - Line spacing

2. Gnus only folks (Difficult to find these)

   - Give them an init file with Gmail (and other popular servers)
     pre-configured and say put your username here and password there.

   - A configuration that enables news.gmane.org and subscribes to *all*
     the emacs related groups.

3. Programming modes

   - Lisp

   - C

   - Perl

   - C++

   - Insert-the-new-language-you-invented

   - Cedet + completion packages

4. International users

   - Germany

   - Russia

   - China

   Recommended fonts, input methods and language settings etc.
   Timezone configuration etc.

5. Windows users

   - Cygwin

   - Libpng, libxml, zip, GnuWin32

6. Mac users

   - Most capslock + control swap folks seem to belong to this group.


7. Gnu/Linux users

   - 

8. Org-mode

   - Text markup users

   - Babel/Literate Programming users

   - GTD nuts

9. Tex + Bibtex users

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> The OP has settled for "suits".
>
> I think "Halloween" would be a good word.  Not only
> that it is funny, it is also scary and also
> functional (During you assume a different personality
> via masks and dresses etc.)

Right. Suit, like in a deck of cards, or the different
outfits on the Starship Enterprise bridge (not
considering that none of those looks either good or
functional: no pockets, no hood etc. so not very warm
either).

Halloween is perhaps better because it is more
"visible". We don't need to be so conservative. But if
the matter is settled "suit" is not a bad choice.

> A good way to think would be to "segment" the users.

A combination of looks and behaviour.

> 2. Gnus only folks (Difficult to find these)
>
>    - Give them an init file with Gmail (and other
> popular servers) pre-configured and say put your
> username here and password there.

As in, using Gnus as an interface to Gmail?
("Interface" as in interface *and* extended toolbox.)
Never thought of that but why not? I use Gnus that way
to my mail service provider. Just that, when you say
"Gmail" you don't think of it as a mail transport
service, you think of the web GUI. (At least I do.)

>    - A configuration that enables news.gmane.org and
> subscribes to *all* the emacs related groups.

How many are there? I know of

comp.emacs (never any traffic)
gnu.emacs.gnus (sparse)
gnu.emacs.help (this group - 5-15 messages a day?)
gnu.emacs.sources (sparse but very ambitious releases)

> 3. Programming modes
>    - Lisp
>    - C
>    - Perl
>    - C++

You wish! More likely: Java, PHP, Ruby, C#... *sob*

It is an uphill battle indeed!

> 7. Gnu/Linux users
>    -

?

> 8. Org-mode
>    - Text markup users
>    - Babel/Literate Programming users
>    - GTD nuts
>
> 9. Tex + Bibtex users

Perhaps those goes with "prose"? I always said, if
writers learned how to do LaTeX the whole publishing
industry would disembark.

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

>>    - A configuration that enables news.gmane.org and
>> subscribes to *all* the emacs related groups.
>
> How many are there? I know of
>
> comp.emacs (never any traffic)
> gnu.emacs.gnus (sparse)
> gnu.emacs.help (this group - 5-15 messages a day?)
> gnu.emacs.sources (sparse but very ambitious releases)

These are the lists that I read

         0: nntp+news.gmane.org:gmane.emacs.sources
         0: nntp+news.gmane.org:gmane.emacs.devel
         0: nntp+news.gmane.org:gmane.emacs.announce
         0: nntp+news.gmane.org:gmane.emacs.cedet
         0: nntp+news.gmane.org:gmane.emacs.gnus.user
         0: nntp+news.gmane.org:gmane.emacs.orgmode
         0: nntp+news.gmane.org:gmane.emacs.bugs
         0: nntp+news.gmane.org:gmane.emacs.help

----------------------------------------------------------------

This is another link

    http://savannah.gnu.org/projects/emacs

There are 10 mailing lists that are considered part of Core Emacs.

    http://savannah.gnu.org/mail/?group=emacs

----------------------------------------------------------------

Here is a list of lists

   http://lists.gnu.org/archive/html/
    
----------------------------------------------------------------

You use gnus right?

Do you use news.gmane.org for your news feeds?  If yes, try this

1. In *Group* buffer

       ^

2. You are now in server buffer.  On the line that looks like this:

       {nntp:news.gmane.org} (opened)

   press

       RET


3. You will get a bunch of newsgroups.  Now do

      M-x occur emacs

4. Go to a list of interest to you and type

      u

   to subscribe

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> These are the lists that I read
>
>          0: nntp+news.gmane.org:gmane.emacs.sources
>          0: nntp+news.gmane.org:gmane.emacs.devel
>          0: nntp+news.gmane.org:gmane.emacs.announce
>          0: nntp+news.gmane.org:gmane.emacs.cedet
>          0: nntp+news.gmane.org:gmane.emacs.gnus.user
>          0: nntp+news.gmane.org:gmane.emacs.orgmode
>          0: nntp+news.gmane.org:gmane.emacs.bugs
>          0: nntp+news.gmane.org:gmane.emacs.help

Now I'm on gmane as well. Yeah, it was only a matter of
chaining -

;; (setq gnus-select-method '(nntp "Aioe.org"))
(setq gnus-select-method '(nntp "news.gmane.org"))

- and this is the same as gnu.emacs.help, only... I
only see *some* of my messages - on the other hand, if
Jambunathan has been on gmane all the while, it must
still work somehow, because he has answered those that
I do not see. (?)

Well, this is all a bit confusing. I don't know if I
should change. Because, just as I couldn't get to gmane
from Aioe, all those other newsgroups, for example

comp.unix.misc (*)
comp.unix.programmer (*)
comp.unix.shell (*)

are now unavailable.

Could you make a case that gmane is better than Aioe?

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

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Emanuel Berg <embe8573@student.uu.se> writes:

> Now I'm on gmane as well. Yeah, it was only a matter of
> chaining -
>
> ;; (setq gnus-select-method '(nntp "Aioe.org"))
> (setq gnus-select-method '(nntp "news.gmane.org"))

Don't you think that this is a snippet that every Emacs + Gnus user
should have?  From your own experience, you see that you ended up
re-inventing the wheel...

If a person familiar with Emacs Lisp goes through this, think about
people who use Emacs but don't know how to program.

Re: RFC: Flavors - naming significant sets of customizations

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

>> Now I'm on gmane as well. Yeah, it was only a matter of
>> chaining -
>>
>> ;; (setq gnus-select-method '(nntp "Aioe.org"))
>> (setq gnus-select-method '(nntp "news.gmane.org"))
>
> Don't you think that this is a snippet that every Emacs + Gnus user
> should have?  From your own experience, you see that you ended up
> re-inventing the wheel...
>
> If a person familiar with Emacs Lisp goes through this, think about
> people who use Emacs but don't know how to program.

What tricks do you have for people who are in the same locale as you?

Same country, same language as ".se".  The spell-checkers and
dictionaries you use, the input method, the most beautiful font, the
calendar holidays etc.

If you can post list of holidays for 2014 don't you think all people
from .se would be interested in it.

People of same country and language should unite!

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> What tricks do you have for people who are in the
> same locale as you?

Well, I have a file for spelling [1] in Emacs. I have a
script (and tutorial) for mucking around with
dictionaries [2] in Debian. I have this page that
describes how to write (or translate) man pages [3]
into Swedish, and then how to enable (show) them from
the shell and from Emacs. I have a file to setup the
compose key [4] to do å, ä, and ö, so you can use those
when you need them, but still have the US layout suited
for programming. Last, I have a Perl script to convert
the weight [5] of boxers (fighting in the US with those
goofy units) into kilograms :)

But again, Swedish programmers are not like me. They do
Java, PHP, C#, etc. It is very sad.

[1] http://user.it.uu.se/~embe8573/conf/.emacs-spell
[2] http://user.it.uu.se/~embe8573/scripts/addict
[3] http://user.it.uu.se/~embe8573/man_sv/index.html
[4] http://user.it.uu.se/~embe8573/conf/remap.inc
[5] http://user.it.uu.se/~embe8573/scripts/ush

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

>> ;; (setq gnus-select-method '(nntp "Aioe.org"))
>> (setq gnus-select-method '(nntp "news.gmane.org"))
>
> Don't you think that this is a snippet that every
> Emacs + Gnus user should have?  From your own
> experience, you see that you ended up re-inventing
> the wheel...

I principle, yes, but those miniature reinventions are
perhaps tolerable. But yes, a Gnus template with those
two lines (or the like), and comments that describe how
Aioe and gmane differ, something I still don't know, by
the way. gmane seems slower. But I got a mail from them
asking me to confirm my identity, so that indicates
they are more aware of spammers and that kind of
people.

> If a person familiar with Emacs Lisp goes through
> this, think about people who use Emacs but don't know
> how to program.

Yes, I'm convinced :)

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> gmane seems slower. But I got a mail from them asking
> me to confirm my identity, so that indicates they are
> more aware of spammers and that kind of people.

On http://www.aioe.org/ I read that

> Aioe.org hosts a public news server, an USENET site
> that is intentionally kept open for all IP addresses
> without requiring any kind of authentication both for
> reading and posting.

Like I said, I got an email requesting I confirm my
identity the first time I posted on gmane, so that
could be an explanation to the slower speed. Also, it
could be that gmane holds much larger archives. Or
even, as I have used Aioe long time, that there is a
more elaborate file tree on my disk.

Anyway, Aioe is not liberal on spammers:

> Spam, pornography, paedophilia, and any kind of
> abuses are not tolerated.

They do this by not having the binary groups, which, I
heard, were the reason for the decline of Usenet (how
many digitized Aldous Huxley articles add up to one
lamer sharing porn?).

They also do it by limiting the number of messages you
can send. I recently got banned that way temporary, but
I found that I got a new IP with

sudo /etc/init.d/networking restart
sudo dhclient eht0

Perhaps that should be done with care...

On the news page, as for gmane, it says:

> gmane.* hierarchy was deleted since a good feed is
> missing for those groups.

Well, that's interesting!

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> These are the lists that I read
>
> 0: nntp+news.gmane.org:gmane.emacs.sources
> 0: nntp+news.gmane.org:gmane.emacs.devel
> 0: nntp+news.gmane.org:gmane.emacs.announce
> 0: nntp+news.gmane.org:gmane.emacs.cedet
> 0: nntp+news.gmane.org:gmane.emacs.gnus.user
> 0: nntp+news.gmane.org:gmane.emacs.orgmode
> 0: nntp+news.gmane.org:gmane.emacs.bugs
> 0: nntp+news.gmane.org:gmane.emacs.help

OK: gmane.emacs.gnus.user is the same as
gnu.emacs.gnus.

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> These are the lists that I read
>
>          0: nntp+news.gmane.org:gmane.emacs.sources
>          0: nntp+news.gmane.org:gmane.emacs.devel
>          0: nntp+news.gmane.org:gmane.emacs.announce
>          0: nntp+news.gmane.org:gmane.emacs.cedet
>          0: nntp+news.gmane.org:gmane.emacs.gnus.user
>          0: nntp+news.gmane.org:gmane.emacs.orgmode
>          0: nntp+news.gmane.org:gmane.emacs.bugs
>          0: nntp+news.gmane.org:gmane.emacs.help

Wow, that's a lot to digest!

No, I never understood this "gmane" thing. Is
gmane.emacs.help not the same as gnu.emacs.help - or is
it just a matter of distribution and/or interface?

It sounds as if it could be some twist on Gmail - like
Postscript and ghostscript, modify and mogrify, etc.

I'll try to add some of those groups right now, hang
on...

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> I'll try to add some of those groups right now, hang
> on...

No, I can't add any of those gmane groups the way I
usually do, with

(setq gnus-select-method '(nntp "Aioe.org"))

and

(defun gnus-add-nntp-group (group)
  (interactive "s Group: ")
  (gnus-group-make-group group "nntp" (nth 1 gnus-select-method))
  (gnus-save-newsrc-file) )

Perhaps they are not on Aioe.org?

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

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Jambunathan K <kjambunathan@gmail.com> writes:

> A good way to think would be to "segment" the users.
>
> If one just puts a starting init file for each of the
> "segment" in GNU ELPA, then this file and library
> itself will become a focal point for consensus
> building.  In a word, the .el file becomes a
> "clearing house" for common or recommended
> configuration.

...although I understand it now, I still don't like
it. It is something "Asperger
syndrome"/schoolboyishness about that whole line of
thinking.

If we have a tool that can do a hundred things, why
market it as "you should use this suite, if you want to
do [a subset] 10 things?" Does that really make sense?

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

Re: RFC: Flavors - naming significant sets of customizations

[Rustom Mody]

On Saturday, November 30, 2013 1:25:02 AM UTC+5:30, Emanuel Berg wrote:
> Jambunathan K writes:
>
> > A good way to think would be to "segment" the users.
> >
> > If one just puts a starting init file for each of the
> > "segment" in GNU ELPA, then this file and library
> > itself will become a focal point for consensus
> > building.  In a word, the .el file becomes a
> > "clearing house" for common or recommended
> > configuration.
>
> ...although I understand it now, I still don't like
> it. It is something "Asperger
> syndrome"/schoolboyishness about that whole line of
> thinking.
>
> If we have a tool that can do a hundred things, why
> market it as "you should use this suite, if you want to
> do [a subset] 10 things?" Does that really make sense?

It makes sense because of a basic principle of psychology:
Tell people (about) what interests them and you attract them.
Tell people what interests you and you bore them.
[Remember your experience with writing letters to Linux Mag?]

Which is why (something like) Jambunathan's list is useful:
Tell someone "emacs is the most super-duper all-powerful editor" and they blink:
Why should I want a super-duper all-powerful editor?
Show them how to solve their current problem and they will be all ears.

[BTW Advertising is a trillion dollar business]

Re: RFC: Flavors - naming significant sets of customizations

[Emanuel Berg]

Rustom Mody <rustompmody@gmail.com> writes:

> It makes sense because of a basic principle of
> psychology: Tell people (about) what interests them
> and you attract them.  Tell people what interests you
> and you bore them.  [Remember your experience with
> writing letters to Linux Mag?]
>
> Which is why (something like) Jambunathan's list is
> useful: Tell someone "emacs is the most super-duper
> all-powerful editor" and they blink: Why should I
> want a super-duper all-powerful editor?  Show them
> how to solve their current problem and they will be
> all ears.

So this is just a PR-stunt to attract newcomers? Phew,
what a relief :)

As for me, I gave up changing other people years ago. I
never succeeded anyway. It is much better to focus on
what *you* believe in because that will never
fail. Every minimal piece of progress will be: a
minimal piece of progress. But this: what if you spend
5 years setting up all kinds of "suites" and they never
attract more than a handful people? That could
happen. Oh no. With *time*, I'm not a gambler.

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

Re: RFC: Flavors - naming significant sets of customizations

[Ted Zlatanov]

On Fri, 29 Nov 2013 15:31:41 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote: 

YK> It just occurred to me that it’s not so much a “taste” or “flavor” as
YK> a “topping”. Meaning, you can usually have just one of the available
YK> flavors, but any subset of available toppings.

http://www.lettersofnote.com/2013/11/may-i-submit-utopian-turtletop.html

Ted