Elisp addiction not as bad in light of Linux forkoholism

Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

There is a detail with Emacs that I don't like, so I
have decided to fork Emacs. I'll call the new project
emh4xs and you can read more on my - ...

Well, if you didn't fall for that, or thought it was a
lame joke, here is an even lamer drama just around the
corner:

On gwene.org.slashdot.linux -

    Archived-at:
    <http://rss.slashdot.org/~r/Slashdot/slashdotLinux/~3/uWE0emOUOd4/story01.htm>

- I just read this:

    The so called "Veteran Unix Admin" collective has
    announced that the fork of Debian will proceed as
    a result of the recent systemd controversy. The
    reasons put forward are not just technical;
    included is a letter of endorsement by Debian
    Developer Roger Leigh mentioning that "people rely
    on Debian for their jobs and businesses, their
    research and their hobbies. It's not a playground
    for such radical experimentation." The fork is
    called "Devuan," pronounced "DevOne." The official
    website has more information.

init is, I think, a remnant of AT&T's UNIX System V.
init has been around on Unix systems a long time,
including Linux systems. init is functional but very
heavy-handed and hackish in style - for example,
running system userspace startup (and exit) processes
- and in what order - relies on the file*names* of
scripts!

For this reason Debian and many others opted for
systemd(1) as a so called "service manager"
replacement for init. The Ubuntu project had their own
competitor going on, but they dropped it when Debian
went for systemd. (Ubuntu itself a Debian fork.)

systemd is more modern (I think, in the future, it'll
be even more modern), and it isn't that hard to
operate -- though I think it could be even simpler, as
it is basically the matter of lunching a bunch of
processes.

So because of some child-diseases and other obstacles
that were to be expected, there has been a constant
ruckus and never-ending hullabaloo where many people -
including those that should probably focus on their
stuff - have expressed dislike in unpleasant ways.

And now, classy old Debian has forked again!

I'd like to bring this to everyone's attention,
because in this nonsense hundreds and thousands of man
hours have been wasted over what should amount to
nothing. (Luckily it didn't take me that long to write
this message :)

The old Emacs pros sometimes like to say you shouldn't
spend too much time configuring Emacs, you shouldn't
get stuck in that, it is ultimately impractical, etc.
- well, OK, you shouldn't! But people like to be
creative and hack their stuff, it is a fact, and at
least our way is one million times better than the
sweet idiocy of the Linux fork-mania.

It is simple: Don't fork - program.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Filipp Gunbin]

What I like about Emacs is that I don't have to think much about the OS.
I worked on Cygwin, it was fine (but slow), now I work on Mac OS X -
it's ok too (and faster - the most impressive difference is when I turn
on `global-auto-revert-mode' after project update from git...).  Same
interface, same environment.  Just don't care about the OS.  (Yes, Mac
OS X is non-free, but I don't mind spying on me if they would want
so...)

Filipp

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> What I like about Emacs is that I don't have to
> think much about the OS. I worked on Cygwin, it was
> fine (but slow), now I work on Mac OS X - it's ok
> too (and faster - the most impressive difference is
> when I turn on `global-auto-revert-mode' after
> project update from git...). Same interface, same
> environment. Just don't care about the OS. (Yes, Mac
> OS X is non-free, but I don't mind spying on me if
> they would want so...)

What you are saying is there are other OSs besides
Emacs?

:)

I used to think if I just had Emacs and a shell to
hammer commands the OS wouldn't matter. That was when
I was young and elastic. Now I'm a bit older and I
only acknowledge that principle in principle. Actually
I'm a bit cut in stone. But at least I know that stone
works (almost) no matter.

No, I don't like Apple for political as well as
personal reasons.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Filipp Gunbin]

On 30/11/2014 02:49 +0100, Emanuel Berg wrote:

> I used to think if I just had Emacs and a shell to hammer commands the
> OS wouldn't matter. That was when I was young and elastic. Now I'm a
> bit older and I only acknowledge that principle in principle. Actually
> I'm a bit cut in stone. But at least I know that stone works (almost)
> no matter.

Just interesting, what OS specifics you are sticking to?

-- 
    Filipp

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

>> I used to think if I just had Emacs and a shell to
>> hammer commands the OS wouldn't matter. That was
>> when I was young and elastic. Now I'm a bit older
>> and I only acknowledge that principle in principle.
>> Actually I'm a bit cut in stone. But at least I
>> know that stone works (almost) no matter.
>
> Just interesting, what OS specifics you are sticking
> to?

I use Debian which is very common among people like
me. I don't know if we are the same from day one or
using the same software made us the same. I think I
could use any Unix-like system though. I consider
Linux do be Unix -- and GNU is obviously not UNIX only
as a clever irony.

As I see it, the thing with writing code is that you
should be able to do it all the time, at every place
of your system.

For example, I can deep into having the time displayed
in a certain way in the shell:

long-date () {
        start_of_month=`date +"%Y%m01"`
        days_of_month=`date -d "$start_of_month + 1 month - 1 day" | cut -d\  -f3`
        full_date="  %b %d %H:%M - %A: week %V - month %m (of $days_of_month days) - %Y"
        tput setaf 3
        /bin/date +$full_date
        tput sgr0
}

Not to mention all Emacs hacking that is just a
bottomless pit, which is a huge part why I love the
software (and a huge part why it is so good).

I don't doubt Windows programmers can be very good as
programmers but they are always working on their big
projects to make money or do big things. But those big
projects are all so distant, and besides the
programmers might not even enjoy those projects
themselves.

I want to do all small things, it is relaxing to do
and when done I enjoy it immediately, and ever since.
The way I perceive Windows programmers working on
their would-be-Quake-killer is that they aren't as
free as us Unixers, they are in the "cage" of the OS,
instead of as fish in the water.

The interface is also a big part in making "small
things, every thing" programming possible because if it
is all just text, and you like it that way, that
speeds up development a hundred times.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Pascal J. Bourguignon]

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

> init is, I think, a remnant of AT&T's UNIX System V.
> init has been around on Unix systems a long time,
> including Linux systems. init is functional but very
> heavy-handed and hackish in style - for example,
> running system userspace startup (and exit) processes
> - and in what order - relies on the file*names* of
> scripts!

You call it hackish, but I find it is an essential unixism.  Using the
file system as a database for unix administration data, keeping other
unix adminstration data in simple text file tables (instead of more
sophisticated, but also much more brittle databases (think for example,
the various versions of Sun NIS (Yellow Pages), NeXT/Apple NetInfo, and
now Directory Services (how long will it last!?)).

This is essential to keep unix administration data in simple text files,
and possibly in structured directories (ie. with file names encoding
things like order of loading or others), because this is what gives unix
its discoverability and ease of administration (and ease of writing
administrative tools).



On the other hand, I don't mind people developping non-unix systems,
using a unix kernel and adding layers, such as Android.  But that should
not trample upon a true unix system.

> So because of some child-diseases and other obstacles
> that were to be expected, there has been a constant
> ruckus and never-ending hullabaloo where many people -
> including those that should probably focus on their
> stuff - have expressed dislike in unpleasant ways.

I've not looked at systemd too closely, but AFAICS, the problem is not
child-diseases, but more that it's not enough unixy.  It's kind of like
launchd on MacOSX, and, while I must admit that launchd finally seems to
work satisfactorily, I wouldn't say that it plays nice from a unix point
of view.


> And now, classy old Debian has forked again!

Ubuntu forked from Debian and it's not a bad thing (arguably).

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Elisp addiction not as bad in light of Linux forkoholism

[Dan Espen]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> I've not looked at systemd too closely, but AFAICS, the problem is not
> child-diseases, but more that it's not enough unixy.

It's like an echo.  I keep reading this same opinion.

1. I don't know much about it
2. It's bad.

Spend a little time appreciating the simplicity of systemd
and then reach your conclusion.  In my opinion, the  design is
good and it takes a whole bunch of disorganized shell scripts
and turns them into data.  I nice simple, readable data structure.

Is it "unixy"?

As if that word meant something, I'd  say yes.
It's just the right amount of code to solve  the problem.

-- 
Dan Espen

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

>> I've not looked at systemd too closely, but AFAICS,
>> the problem is not child-diseases, but more that
>> it's not enough unixy.
>
> It's like an echo. I keep reading this same opinion.
>
> 1. I don't know much about it 2. It's bad.
>
> Spend a little time appreciating the simplicity of
> systemd and then reach your conclusion. In my
> opinion, the design is good and it takes a whole
> bunch of disorganized shell scripts and turns them
> into data. I nice simple, readable data structure.
>
> Is it "unixy"?
>
> As if that word meant something, I'd say yes. It's
> just the right amount of code to solve the problem.

Well, yeah, and regardless of whatever it is
absolutely nothing to get all heated-up about, not to
mention forking Debian which is a farse.

Maybe they did that as a scam just so people would
stop the litany. Now they can tell the whiners - if
you don't like it, join the forked Debian!. (By the
way, I expect that project not exactly to hit the
top-ten list of the Eurovision song contest.)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Pascal J. Bourguignon]

Dan Espen <despen@verizon.net> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>
>> I've not looked at systemd too closely, but AFAICS, the problem is not
>> child-diseases, but more that it's not enough unixy.
>
> It's like an echo.  I keep reading this same opinion.
>
> 1. I don't know much about it
> 2. It's bad.
>
> Spend a little time appreciating the simplicity of systemd
> and then reach your conclusion.  In my opinion, the  design is
> good and it takes a whole bunch of disorganized shell scripts
> and turns them into data.  I nice simple, readable data structure.

Notice that you're the first one I read expressing this judgement about
systemd.  It's certainly encouraging to have a closer look at it.


> Is it "unixy"?
>
> As if that word meant something, I'd  say yes.
> It's just the right amount of code to solve  the problem.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Elisp addiction not as bad in light of Linux forkoholism

[Dan Espen]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>>
>>> I've not looked at systemd too closely, but AFAICS, the problem is not
>>> child-diseases, but more that it's not enough unixy.
>>
>> It's like an echo.  I keep reading this same opinion.
>>
>> 1. I don't know much about it
>> 2. It's bad.
>>
>> Spend a little time appreciating the simplicity of systemd
>> and then reach your conclusion.  In my opinion, the  design is
>> good and it takes a whole bunch of disorganized shell scripts
>> and turns them into data.  I nice simple, readable data structure.
>
> Notice that you're the first one I read expressing this judgement about
> systemd.  It's certainly encouraging to have a closer look at it.

Seems to me we have a culture that encourages disparaging everything.

I do notice that common pattern of the people bad-talking systemd
all starting out with "I don't know much about it".

That encouraged me to take a look.
I had no reason to look before then because I had no problems working
with it.  I noticed some commands changed, but they worked perfectly.

One of the primary attributes of systemd is that it took a whole bunch
of daemon admin scripts, found the commonalities, then replaced
them with data files.

This attitude that I know better than the experts is dumb.
At least learn something before you open your mouth.
(Not you, the generic you.)

-- 
Dan Espen

Re: Elisp addiction not as bad in light of Linux forkoholism

[Rostislav Svoboda]

> 1. I don't know much about it
> 2. It's bad.

In general this argumentation may appear in a new light if one restates
it as:

1. I don't know much about it, because it is/looks too complicated
and/or hard to learn.

Take as an example the crontab editing. Not really that complicated
but definitely nothing for a newbie.  (BTW I just opened it using
nano, so from now on nano is my default crontab editor - and now I
gotta figure out how to undo this setting. Whata shot in a leg!)

Re: Elisp addiction not as bad in light of Linux forkoholism

[Dan Espen]

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:

>> 1. I don't know much about it
>> 2. It's bad.
>
> In general this argumentation may appear in a new light if one restates
> it as:
>
> 1. I don't know much about it, because it is/looks too complicated
> and/or hard to learn.

Strangely enough, those are not the complaints I see.
Number one is "unix philosophy", followed closely by
monolithic.

Of course one program than changes dozens of scripts to data files
is monolithic.  But I don't hear anyone saying they used to be able
to do "x" in a script and systemd can't do  the same.  In fact,
systemd was able to duplicate the function of all those scrupts.

> Take as an example the crontab editing. Not really that complicated
> but definitely nothing for a newbie.  (BTW I just opened it using
> nano, so from now on nano is my default crontab editor - and now I
> gotta figure out how to undo this setting. Whata shot in a leg!)

I just used nano to open my "cron.linux" file.  To special joy at all.
Then I tried x.cron but nano didn't seem excited.

However, emacs does something useful with the comments at the
end of my cron.linux file:

# Local Variables:
# compile-command: "crontab ~/cron.linux"
# End:


-- 
Dan Espen

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Rostislav Svoboda <rostislav.svoboda@gmail.com>
writes:

> 1. I don't know much about it, because it is/looks
> too complicated and/or hard to learn.

I think it absolutely looks very complicated going
around it. That was my impression as well. For
starting processes after boot, I think there should
just be a list of commands. That would be just like
init only instead of those file names and directories
it could be a file with data so you could edit it just
like any other.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> init is, I think, a remnant of AT&T's UNIX System
>> V. init has been around on Unix systems a long
>> time, including Linux systems. init is functional
>> but very heavy-handed and hackish in style - for
>> example, running system userspace startup (and
>> exit) processes - and in what order - relies on the
>> file*names* of scripts!
>
> You call it hackish, but I find it is an essential
> unixism. Using the file system as a database for
> unix administration data, keeping other unix
> adminstration data in simple text file tables
> (instead of more sophisticated, but also much more
> brittle databases (think for example, the various
> versions of Sun NIS (Yellow Pages), NeXT/Apple
> NetInfo, and now Directory Services (how long will
> it last!?)).
>
> This is essential to keep unix administration data
> in simple text files, and possibly in structured
> directories (ie. with file names encoding things
> like order of loading or others), because this is
> what gives unix its discoverability and ease of
> administration (and ease of writing administrative
> tools).
>
> On the other hand, I don't mind people developping
> non-unix systems, using a unix kernel and adding
> layers, such as Android. But that should not trample
> upon a true unix system.

Don't even true unix systems have to change?

But I don't think init is bad. The script name
solution isn't what we expect today when we hope to
just add or remove stuff regardless of what is already
there, but I have mucked around with that myself and
it was straightforward with the runlevels as
directories and "services" (?) as scripts. (Yes, that
is a very Unix solution.)

>> So because of some child-diseases and other
>> obstacles that were to be expected, there has been
>> a constant ruckus and never-ending hullabaloo where
>> many people - including those that should probably
>> focus on their stuff - have expressed dislike in
>> unpleasant ways.
>
> I've not looked at systemd too closely, but AFAICS,
> the problem is not child-diseases, but more that
> it's not enough unixy. It's kind of like launchd on
> MacOSX, and, while I must admit that launchd finally
> seems to work satisfactorily, I wouldn't say that it
> plays nice from a unix point of view.

I got systemd to work almost instantly the way init
did, but it was more complicated than init as I had to
wade through scripts with code that I didn't
understand, and then add a couple of lines. It worked,
but init is more clear for my purposes. But I would
suspect systemd brings something to the table for
those who does this more often and thus take the time
to understand the new system. Actually it is enough
for me that Debian opted for it: I trust them.

>> And now, classy old Debian has forked again!
>
> Ubuntu forked from Debian and it's not a bad thing
> (arguably).

Forking is not a bad thing conceptually, it is rather
it should be done when an all-but undividable piece of
software is at a crossroad and people want to take
different roads.

For example, let's say there is code for a basic
calculator. Some people want to keep it simple (keep
it as it is), some people wants to do a GUI and make
it a plotter as well, and some third people want to
stick with CLI but extend it into a scientific
calculator with e and powers and all.

Now, what I would do is: do *all* of that, and then
have it configurable! But OK, a fork is a good option
as well because then the basic code can be reused.

On the other hand, when I am against forking (as an
opinion, of course I'm not saying it should be
hindered in practice) - when I am against forking is
when the fork is on some big system, but is due to a
small software component that should be all modular
already.

So forking systemd to do a different systemd (let's
call it systemd2) is OK, but not to fork Debian
because some people prefer systemd to systemd2. Why
not just make it optional?

Forking OSs (distros) involves so much overhead it is
much better to put that time into (modular) software.
That would get us better software and people would be
more inclined to compose their own systems *within* a
system. So instead of distro hopper we would have
better computer users as well.

-- 
underground experts united

Emacs and Unix (was: Re: Elisp addiction not as bad in light of Linux forkoholism)

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> I find it is an essential unixism

Speaking of Unix and Emacs, many Unix devotees like to
bring up the Unix software philosophy, that should
amount to

* software stick to their field, and carry out their
  particular task and nothing else, and that task can
  be very simple indeed
  
* but all software share the same interface - this is
  arguments, pipes, streams, redirection, perhaps even
  shell features like backticks and so on

* and data is always the same: text

This means you can combine simple software to do more
and more complicated things.

People talk about "modular" software, but this
toolchain architecture is by definition modular.

Question is: is Emacs "Unix" as well?

Problem is, the Unix philosophy applies best to batch
software, like CLI computation, old-school black-box
computing where data in one form is inputted, and then
the same data, but modified or arranged differently,
is outputted.

My gut feeling is that Emacs could be Unix only
interactive, and that the text stream data type is the
Emacs buffer. I mean, it is not important for me that
Emacs is Unix, I know there are emacses on many other
OSs, but one sure sees similarities of approaches with
the "one interface, one data type", not to mention the
practical side to have a text editor to navigate and
interact with as system that is all a bunch of
textfiles.

But to some degree, I think Emacs is cooler and more
advanced than Unix. The strength of the Unix system
architecture - that everything are files and processes
- must have been very hard figuring out, but once
there it is a straightforward implementation of a
simple program. Emacs on the other hand is not Unix at
all when it comes to processes and such. But of course
it wouldn't make sense to make Unix to run on top of
Unix...

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Marcin Borkowski]

On 2014-11-30, at 01:06, Emanuel Berg wrote:

> It is simple: Don't fork - program.

Wow, it's rant time!

So you're in for a treat: I have a spare minute, and let me share a
story with you.  (I guess I read it in some interview, I don't remember
now.)

When DEK coded TeX (and published the cource code), he thought that many
people will actually customize TeX (=the engine) to their needs.  It
turned out that (apparently) the macro programming was more powerful
than he expected: almost nobody did that, people did wonderful things at
the macro level, without ever touching the source code (apart from
increasing the memory constraints, which required recompliation back
then).  This includes not only LaTeX and its styles (later: classes and
packages), but also a BASIC and Lisp interpreters, a few numerical
engines, a regex engine (recently), an XML parser and much more.  (This
is, in fact, an oversimplification; some of these things require e-TeX,
which is a relatively small extension to the engine.)

The real hacking on the underlying engine did happen, of course, but not
that often.  Most notably, we have e-TeX, pdfTeX (which is great),
pdfeTeX (which combines both of them); then we have XeTeX (originally
only on Mac, now also Win and Linux), Omega and Aleph, and - most
recently - LuaTeX (which is the most serious modification, and a very
well designed one AFAIK).  (There were admittedly smaller extensions,
like encTeX, but they could be technically just patches, not "forks".)
Not really that many "forks", for a program more than 30 years old.
Especially that eTeX and pdf(e)TeX are not considered forks now, rather
legal successors (hardly anyone uses the original tex engine nowadays),
and LuaTeX gains more and more traction; some (me included) hope that it
will mostly replace the more conservative versions some day.  (LuaTeX is
AFAIK the only one which took the idea of giving TeX really new things
seriously.)

(Well, there was also NTS, but it was really a clone, not a fork, and it
is almost "evaporated" in Orwellian sense (even the sources are nowhere
on the 'net!) - go figure.)

I guess it is a bit similar as in the Emacs world.  If you make a
program flexible enough, people won't fork it too much - they just won't
need it.  (The existing forks solved some /real problems/: 8-bit-ness
with Omega, complicated dvi->ps->pdf route with pdfTeX, limited
registers and other constraints with eTeX, impossibility of RtL
typesetting with Omega and XeTeX, lack of access to system fonts with
XeTeX, problems with advanced programming and other things with LuaTeX.)

Just my 2 cents.

(And re: Debian vs Ubuntu, I never used Debian, but Ubuntu is a huge
disappointment: it has been less and less usable recently (especially
compared to, say, five or seven years ago), and it will be kicked out of
my machine when I have a few spare days to do a reinstall.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>> It is simple: Don't fork - program.
>
> Wow, it's rant time!
>
> So you're in for a treat: I have a spare minute, and
> let me share a story with you. (I guess I read it in
> some interview, I don't remember now.)

...but for a lot of stuff you seem to have an
excellent memory.

> When DEK coded TeX (and published the cource code),
> he thought that many people will actually customize
> TeX (= the engine) to their needs. It turned out
> that (apparently) the macro programming was more
> powerful than he expected: almost nobody did that,
> people did wonderful things at the macro level,
> without ever touching the source code (apart from
> increasing the memory constraints, which required
> recompliation back then). This includes not only
> LaTeX and its styles (later: classes and packages),
> but also a BASIC and Lisp interpreters, a few
> numerical engines, a regex engine (recently), an XML
> parser and much more. (This is, in fact, an
> oversimplification; some of these things require
> e-TeX, which is a relatively small extension to the
> engine.)
>
> The real hacking on the underlying engine did
> happen, of course, but not that often. Most notably,
> we have e-TeX, pdfTeX (which is great), pdfeTeX
> (which combines both of them); then we have XeTeX
> (originally only on Mac, now also Win and Linux),
> Omega and Aleph, and - most recently - LuaTeX (which
> is the most serious modification, and a very well
> designed one AFAIK). (There were admittedly smaller
> extensions, like encTeX, but they could be
> technically just patches, not "forks".) Not really
> that many "forks", for a program more than 30 years
> old. Especially that eTeX and pdf(e)TeX are not
> considered forks now, rather legal successors
> (hardly anyone uses the original tex engine
> nowadays), and LuaTeX gains more and more traction;
> some (me included) hope that it will mostly replace
> the more conservative versions some day. (LuaTeX is
> AFAIK the only one which took the idea of giving TeX
> really new things seriously.)
>
> (Well, there was also NTS, but it was really a
> clone, not a fork, and it is almost "evaporated" in
> Orwellian sense (even the sources are nowhere on the
> 'net!) - go figure.)
>
> I guess it is a bit similar as in the Emacs world.
> If you make a program flexible enough, people won't
> fork it too much - they just won't need it.

That's absolutely right. But the question is: do
people really need to fork Debian just to use init
instead of systemd? init, of course, was used in
Debian until very recently (I first saw systemd on a
3.17.1 kernel). If indeed impossible, Debian is in
part to blame.

And there is no doubt that the Emacs C/Lisp
architecture really makes extension smooth (I can't
think of any better way) - just type the code and
evaluate, using the same software, with immediate
effectuation - no need even to restart the program,
let alone recompile the whole thing.

That said, I think it *is* very possible to get init
to work on the most recent Debian releases as well. A
distro is by definition just a way of putting many,
many things together. Forking just to replace one of
those puzzle pieces with another is like blowing up
the terrorist camp to free the hostages.

> (The existing forks solved some /real problems/:
> 8-bit-ness with Omega, complicated dvi->ps->pdf
> route with pdfTeX, limited registers and other
> constraints with eTeX, impossibility of RtL
> typesetting with Omega and XeTeX, lack of access to
> system fonts with XeTeX, problems with advanced
> programming and other things with LuaTeX.)

There is a lot of LaTeX in you post. Consider posting
it on comp.text.tex or on you home page, if you have
one.

Yes, I use xelatex on Linux to compile LaTeX.
Previously I used pdflatex but I changed because of
some Unicode issues.

I think it is natural with a couple of parallel
versions/dialects/implementations for huge software
systems. That has always been the case. But Linux
distributions? I can't give you an exact figure, but
it is several hundreds.

And it makes even less sense as Linux is a basically
non-interactive kernel. I don't see why you can't just
use it to run whatever software you like?

> Just my 2 cents.
>
> (And re: Debian vs Ubuntu, I never used Debian, but
> Ubuntu is a huge disappointment: it has been less
> and less usable recently (especially compared to,
> say, five or seven years ago), and it will be kicked
> out of my machine when I have a few spare days to do
> a reinstall.)

Typically, the coolest and most experienced people use
Debian :) I never used Ubuntu but most people I meet
who are Linux users use it. So it can't be that bad.
It is oriented to desktop people, though now Canonical
wants the mobile market as well. Ubuntu is in a way
Debian + Apple: the system is basically Debian but on
the top they have been very active with polishing, and
to the left and right, "lifestyle marketing" has not
been neglected.

Also remember that the Debian fork Ubuntu has been
forked many times for similarly questionable reasons:
Kubuntu (to have it in KDE instead of GNOME), Xubuntu
(ditto Xfce), and so on. (Sometimes I think the WM
developers do that just to market their software.)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Marcin Borkowski]

On 2014-11-30, at 18:35, Emanuel Berg wrote:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>>> It is simple: Don't fork - program.
>>
>> Wow, it's rant time!
>>
>> So you're in for a treat: I have a spare minute, and
>> let me share a story with you. (I guess I read it in
>> some interview, I don't remember now.)
>
> ...but for a lot of stuff you seem to have an
> excellent memory.

Thanks.  BTW, I was imprecise: the DEK story I read was just the first
two sentences, the rest was my stream of consciousness;-).

>> When DEK coded TeX (and published the cource code),
>> he thought that many people will actually customize
>> TeX (= the engine) to their needs. It turned out
>> that (apparently) the macro programming was more
>> powerful than he expected: almost nobody did that,
>> people did wonderful things at the macro level,
>> without ever touching the source code (apart from
>> increasing the memory constraints, which required
>> recompliation back then). This includes not only
>> LaTeX and its styles (later: classes and packages),
>> but also a BASIC and Lisp interpreters, a few
>> numerical engines, a regex engine (recently), an XML
>> parser and much more. (This is, in fact, an
>> oversimplification; some of these things require
>> e-TeX, which is a relatively small extension to the
>> engine.)
>>
>> The real hacking on the underlying engine did
>> happen, of course, but not that often. Most notably,
>> we have e-TeX, pdfTeX (which is great), pdfeTeX
>> (which combines both of them); then we have XeTeX
>> (originally only on Mac, now also Win and Linux),
>> Omega and Aleph, and - most recently - LuaTeX (which
>> is the most serious modification, and a very well
>> designed one AFAIK). (There were admittedly smaller
>> extensions, like encTeX, but they could be
>> technically just patches, not "forks".) Not really
>> that many "forks", for a program more than 30 years
>> old. Especially that eTeX and pdf(e)TeX are not
>> considered forks now, rather legal successors
>> (hardly anyone uses the original tex engine
>> nowadays), and LuaTeX gains more and more traction;
>> some (me included) hope that it will mostly replace
>> the more conservative versions some day. (LuaTeX is
>> AFAIK the only one which took the idea of giving TeX
>> really new things seriously.)
>>
>> (Well, there was also NTS, but it was really a
>> clone, not a fork, and it is almost "evaporated" in
>> Orwellian sense (even the sources are nowhere on the
>> 'net!) - go figure.)
>>
>> I guess it is a bit similar as in the Emacs world.
>> If you make a program flexible enough, people won't
>> fork it too much - they just won't need it.
>
> That's absolutely right. But the question is: do
> people really need to fork Debian just to use init
> instead of systemd? init, of course, was used in
> Debian until very recently (I first saw systemd on a
> 3.17.1 kernel). If indeed impossible, Debian is in
> part to blame.

No idea.  I'm just a humble mathematician, I know next to nothing about
OS inner workings.

> And there is no doubt that the Emacs C/Lisp
> architecture really makes extension smooth (I can't
> think of any better way) - just type the code and
> evaluate, using the same software, with immediate
> effectuation - no need even to restart the program,
> let alone recompile the whole thing.

Exactly.  Not the same (but similar) with (La)TeX; we TeX users are so
accustomed to running TeX aagain and again on a file that we may
subconsciously treat it as an interactive process;-).

> That said, I think it *is* very possible to get init
> to work on the most recent Debian releases as well. A
> distro is by definition just a way of putting many,
> many things together. Forking just to replace one of
> those puzzle pieces with another is like blowing up
> the terrorist camp to free the hostages.

Fair enough.

>> (The existing forks solved some /real problems/:
>> 8-bit-ness with Omega, complicated dvi->ps->pdf
>> route with pdfTeX, limited registers and other
>> constraints with eTeX, impossibility of RtL
>> typesetting with Omega and XeTeX, lack of access to
>> system fonts with XeTeX, problems with advanced
>> programming and other things with LuaTeX.)
>
> There is a lot of LaTeX in you post. Consider posting
> it on comp.text.tex or on you home page, if you have
> one.

Well, I guess it is more or less common knowledge among experienced TeX
hackers.  And newbie TeX users don't care.  (You know, these kids of
today...;-).)

Shameless plug: http://mbork.pl .  Quite some (La)TeX stuff, and mainly
Emacs stuff lately (postings on average once a week, usually Saturdays).
Some of that in Polish, but I switched to almost exclusively posting in
English.  (Sadly, this switch temporarily eliminated one of my favourite
topics where I have no enough knowledge of English vocabulary; will work
on that.)

> Yes, I use xelatex on Linux to compile LaTeX.
> Previously I used pdflatex but I changed because of
> some Unicode issues.

Exactly.  There is inputenc, but it is prosthesis, not a "real"
solution.  (It works by messing with active characters.  Those of you
who know a bit about low-level TeX know how dangerous it is, especially
when you write to external files, like, you know, .toc.)  That's why
XeTeX (or LuaTeX) is a good idea nowadays.  (That said, I mostly use
pdfetex myself.  LuaTeX is too slow, and I don't really need much more
than pdfetex + LaTeX + inputenc, usually.)

BTW, Unicode has its own share of problems.  This:
http://www.fileformat.info/info/unicode/char/fe18/index.htm is not the
most serious, but probably the funniest.  A more serious one is mixing
German closing quotation mark with English opening one (IIRC): they
indeed do look identical, but should have different bounding boxes.  And
this is the cutest I know of: look closely at
http://www.fileformat.info/info/unicode/block/mathematical_alphanumeric_symbols/list.htm
and try to guess what happened to "Mathematical italic small h
(U+1D455)".  (Solution: it is at U+210E.  How sweet.)

> I think it is natural with a couple of parallel
> versions/dialects/implementations for huge software
> systems. That has always been the case. But Linux
> distributions? I can't give you an exact figure, but
> it is several hundreds.

Yes, this is craziness.  Maybe it's because they are too monolithic?
There was once PLD Linux which claimed to be more flexible, but it was
extremely difficult to use.  (Though its package manager was pure
genius, rpm-based but with a /fantastic/ interactive shell.)

> And it makes even less sense as Linux is a basically
> non-interactive kernel. I don't see why you can't just
> use it to run whatever software you like?

In theory, yes.  In practice, this is more difficult.  I mean, Emacs on
Ubuntu should be as simple as sudo apt-get install emacs; but then, in
most points in time, this got you an ancient version.  The same with
TeX, and other things.  So step by step you install more and more things
manually, and then why not get Gentoo?

>> Just my 2 cents.
>>
>> (And re: Debian vs Ubuntu, I never used Debian, but
>> Ubuntu is a huge disappointment: it has been less
>> and less usable recently (especially compared to,
>> say, five or seven years ago), and it will be kicked
>> out of my machine when I have a few spare days to do
>> a reinstall.)
>
> Typically, the coolest and most experienced people use
> Debian :) I never used Ubuntu but most people I meet
> who are Linux users use it. So it can't be that bad.
> It is oriented to desktop people, though now Canonical
> wants the mobile market as well. Ubuntu is in a way
> Debian + Apple: the system is basically Debian but on
> the top they have been very active with polishing, and
> to the left and right, "lifestyle marketing" has not
> been neglected.

Debian might be a good idea, but I feel more and more inclined towards
Fedora (or Arch, on days I'm feeling more bold).

> Also remember that the Debian fork Ubuntu has been
> forked many times for similarly questionable reasons:
> Kubuntu (to have it in KDE instead of GNOME), Xubuntu
> (ditto Xfce), and so on. (Sometimes I think the WM
> developers do that just to market their software.)

Yes, I even used some of them for some time.  My goal is to set up a
decent tiling WM (preferably StumpWM, maybe Awesome), so I'm not really
interested in this KDE/Gnome/Unity/whatever dispute.  (The main goal is
to have Emacs occupy the whole screen, without these stupid decorations,
and get rid of the mouse/touchpad.  I hardly ever use anything but
Emacs, a terminal, Evince and Firefox or Chrome anyway.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Elisp addiction not as bad in light of Linux forkoholism

[H. Dieter Wilhelm]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
...

> In theory, yes.  In practice, this is more difficult.  I mean, Emacs on
> Ubuntu should be as simple as sudo apt-get install emacs; but then, in
> most points in time, this got you an ancient version.  The same with
> TeX, and other things.  So step by step you install more and more things
> manually, and then why not get Gentoo?

...

> Debian might be a good idea, but I feel more and more inclined towards
> Fedora (or Arch, on days I'm feeling more bold).

The upcoming Debian (Jessie, Debian 8) is now in freeze and has
emacs-24.4.  By chance I just had to install it and if you are
interested I can give you a quick installation guide privately.

>> Also remember that the Debian fork Ubuntu has been
>> forked many times for similarly questionable reasons:
>> Kubuntu (to have it in KDE instead of GNOME), Xubuntu
>> (ditto Xfce), and so on. (Sometimes I think the WM
>> developers do that just to market their software.)
>
> Yes, I even used some of them for some time.  My goal is to set up a
> decent tiling WM (preferably StumpWM, maybe Awesome), so I'm not really
> interested in this KDE/Gnome/Unity/whatever dispute.  (The main goal is
> to have Emacs occupy the whole screen, without these stupid decorations,
> and get rid of the mouse/touchpad.  I hardly ever use anything but
> Emacs, a terminal, Evince and Firefox or Chrome anyway.)

I'm using Emacs mostly in full-screen mode so, thankfully the desktop
stuff (xfce in my case) matters less and less.  I'm also getting used to
eww, the fast text browser, terminal-mode and doc-view-mode (with
auto-revert-mode for pdfs) more and more.

      Dieter

-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
writes:

> The upcoming Debian (Jessie, Debian 8) is now in
> freeze and has emacs-24.4. By chance I just had to
> install it and if you are interested I can give you
> a quick installation guide privately.

I have 24.4 as well and I got that straight from the
repos with aptitude.

What are you guys talking about? :)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Marcin Borkowski]

On 2014-11-30, at 20:43, Emanuel Berg wrote:

> dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
> writes:
>
>> The upcoming Debian (Jessie, Debian 8) is now in
>> freeze and has emacs-24.4. By chance I just had to
>> install it and if you are interested I can give you
>> a quick installation guide privately.
>
> I have 24.4 as well and I got that straight from the
> repos with aptitude.
>
> What are you guys talking about? :)

Maybe nowadays it's better.  Don't know.  This is not really the worst
thing about Ubuntu, anyway.  When I hit C-M-t to start a terminal, I
have to wait approximately 8 seconds.  When I hit the "Windoze" key to
start the "dash" (I guess this is what it's called), I have to wait
approximately 6 seconds.  Not really a best user experience.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>> I have 24.4 as well and I got that straight from
>> the repos with aptitude. What are you guys talking
>> about? :)
>
> Maybe nowadays it's better. Don't know. This is not
> really the worst thing about Ubuntu, anyway.

Again, I don't use Ubuntu but I always thought the
aptitude stuff worked close to the same for all Debian
forks (and dpkg based distros), though the policy for
the repositories vary. Ubuntu has its own set, but
Knoppix uses those of the stable Debian release, for
example. (Knoppix, originally a "Live CD" Debian fork,
now profiled as a "rescue distro" for broken machines,
itself forked a couple of times.)

> When I hit C-M-t to start a terminal, I have to wait
> approximately 8 seconds.

Do you have those with xbindkeys or do you mean from
Emacs? But either way, it shouldn't take that long.
Ubuntu is considered very "bloated" for a Linux
distro, which generally means it has a lot of stuff
going on under the surface Windoze-style with popups
and other irritating stuff. That of course is a burden
on the system and in particular it can slow down the
interactive feel and responsiveness, and this reduces a
lot the quality-of-life for the computer user, hour by
hour.

It seems GUI OS developers think people have, or will
soon have anyway, computers much faster than those
they actually have. How many threads and question have
you seen online: I don't want this, how do I disable
that, etc.? And how many: I want a small clock, a
calendar, a funny fish, backgrounds that rotate in
four dimensions, etc.? But I understand people want to
be active and creative. All the distro mania as about
that. So even if the form sucks to a great degree
there is some magic energy to it, for sure.

And I still never saw a full-blown DE that came with
the touch-speed of a sweet lonesome terminal.

> When I hit the "Windoze" key to start the "dash" (I
> guess this is what it's called), I have to wait
> approximately 6 seconds. Not really a best user
> experience.

"dash" as in Debian Almquist shell?

One way that works to make the computer faster is to
disable the login manager and then start X manually.
Then just put the stuff you want in xinitrc. The rest,
you won't get. If the computer is slow with just a WM
(e.g. openbox) and xterm, then something is seriously
wrong :)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[H. Dieter Wilhelm]

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

> dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
> writes:
>
>> The upcoming Debian (Jessie, Debian 8) is now in
>> freeze and has emacs-24.4. By chance I just had to
>> install it and if you are interested I can give you
>> a quick installation guide privately.
>
> I have 24.4 as well and I got that straight from the
> repos with aptitude.
>
> What are you guys talking about? :)

Well, sure compiling is an option as well, but usually it's more
convenient to use the distro's packages.  For example, you want to have
bbdb3?

sudo aptitude install bbdb3

that's it.  No searching in github, No fiddling with load-path or other
stuff.

You want to have maxima support of Emacs, R (ess) support?  Likewise.

       Dieter
-- 
Best wishes
H. Dieter Wilhelm
Darmstadt, Germany

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm)
writes:

>>> The upcoming Debian (Jessie, Debian 8) is now in
>>> freeze and has emacs-24.4. By chance I just had to
>>> install it and if you are interested I can give
>>> you a quick installation guide privately.
>>
>> I have 24.4 as well and I got that straight from
>> the repos with aptitude. What are you guys talking
>> about? :)
>
> Well, sure compiling is an option as well, but
> usually it's more convenient to use the distro's
> packages. For example, you want to have bbdb3?
>
> sudo aptitude install bbdb3

Yeah...? No, I use aptitude for everything as well.
That is one of the really big breezes of fresh air (or
tornados I should say) which most people experience
when they switch from Windoze to a packet-manager
Unix-like systems like Linux/Debian. Not having to
wade through all those search engines, sites and
banners, having to "confirm" mails with codes, silly
popups counting the days before it "expires", all that
just to get a piece of software, when you have seen
the other side when none of that is needed, it is very
difficult to go back without feeling like an idiot.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Exactly. Not the same (but similar) with (La)TeX; we
> TeX users are so accustomed to running TeX aagain and
> again on a file that we may subconsciously treat it as
> an interactive process;-).

Yes, recompilation of huge documents for small
changes isn't fun, especially when it has to be done
all over to get references, index, stuff like that.

Here is my makefile for my latest document:

name = report
texc = xelatex
texf = -halt-on-error

${name}.pdf: ${name}.tex ${name}.bib
	$(texc) $(texf) ${name}.tex
	makeindex ${name}.idx 2> /dev/null
	biber ${name} > /dev/null
	$(texc) $(texf) ${name}.tex > /dev/null

clean:
	zsh -c 'rm -rf in missfont.log ${name}.(aux|bbl|bcf|bib.blg|blg|log|run.xml|toc|pdf|out|idx|ilg|ind)'

As you see, two compilation. Imagine that when you
just fix a typo.

> Shameless plug: http://mbork.pl . Quite some (La)TeX
> stuff, and mainly Emacs stuff lately (postings on
> average once a week, usually Saturdays). Some of
> that in Polish, but I switched to almost exclusively
> posting in English. (Sadly, this switch temporarily
> eliminated one of my favourite topics where I have
> no enough knowledge of English vocabulary; will work
> on that.)

Some things that are not computers I write of as if
they were. I first thought people would think it a
strange style but on the contrary they appreciate it
so I definitely think all this computer reading and
writing benefited my skills in doing the same for
other topics as well.

For computers, doing it in my native language isn't
exactly a problem but I prefer English. Just so much
more practice and otherwise I would have to either use
English words all the time or make up uncomfortable
translations. It is in some ways an unlucky state but
it is a reality.

But a good book (or article, speech, etc.) in any
language (that you understand) is always better than a
poor one in your prefered language.

> In theory, yes. In practice, this is more difficult.
> I mean, Emacs on Ubuntu should be as simple as sudo
> apt-get install emacs; but then, in most points in
> time, this got you an ancient version. The same with
> TeX, and other things. So step by step you install
> more and more things manually, and then why not get
> Gentoo?

If that is so I see why you didn't like Ubuntu. No,
Debian can be used year-out year-in only using
aptitude and the associated tools. Nothing manual. I
think Ubuntu should be the same so either you were
unlucky or it isn't, but Ubuntu is aptitude (or
apt-get) based too, as you know.

> Yes, I even used some of them for some time. My goal
> is to set up a decent tiling WM (preferably StumpWM,
> maybe Awesome), so I'm not really interested in this
> KDE/Gnome/Unity/whatever dispute. (The main goal is
> to have Emacs occupy the whole screen, without these
> stupid decorations, and get rid of the
> mouse/touchpad. I hardly ever use anything but
> Emacs, a terminal, Evince and Firefox or Chrome
> anyway.)

To have Emacs occupy the whole screen is easy. You can
put it in the Linux VTs as I do but probably you want
it in X. That's easy too. With a window manager you
can have it in a terminal emulator (xterm for example)
and then have the xterm window maximized with
-fullscreen, and then have it all automatized in
~/.xinitrc and additionally configured in
~/.Xresources, e.g.

! xterm
xterm*autoWrap:        true
xterm*faceName:        xft:bitstram vera sans mono:size=15:antialias=true
xterm*metaSendsEscape: true

!! xterm colors
! normal
xterm*color0:  #000000 // black
xterm*color1:  #B40000 // red
etc.

If what you want is fullscreen Emacs, that goal is
attainable :)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Nikolay Kudryavtsev]

I think Erik Naggum supported a fork of emacs back in the day, because 
he hated MULE.

And I'm not even mentioning xemacs, and other emacsen.

-- 
Best Regards,
Nikolay Kudryavtsev

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
writes:

> I think Erik Naggum supported a fork of emacs back
> in the day, because he hated MULE.
>
> And I'm not even mentioning xemacs, and other
> emacsen.

You actually did mention xemacs, either that or I'm
hallucinating because of too much head trauma trying
to think straight.

C'mon. There is always an exception to a rule, and
there is always an extreme example that makes all
generalizing thoughts impossible.

For example: all people are unique, but that doesn't
stop us from having hospitals were practices are based
on us being 99% the same.

Here is a list of Linux distributions:

    http://en.wikipedia.org/wiki/List_of_Linux_distributions

Do you have anything near that for Emacs?

In a way it makes sense for *Linux* to be "forked"
because of different physical settings and hardware
needs ("ported" is perhaps the word then). But all
those distros, over and over? Oh, no.

There is no doubt in my mind Emacs has been tinkered
with just as much but only minimally forked. Forking
is the poor-man's "configuration and extention", as
they call it on the covers of Emacs books.

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Raffaele Ricciardi]

On 30/11/14 01:06, Emanuel Berg wrote:
> The old Emacs pros sometimes like to say you shouldn't
> spend too much time configuring Emacs, you shouldn't
> get stuck in that, it is ultimately impractical, etc.

The problem is that old Emacs pros don't explain the Emacs work-flow to 
novices and therefore novices are left to "connect the dots" on their 
own.  When novices fail to connect some dots, they resort to configure 
Emacs to achieve some goals in a way that they know.  Moreover, in my 
experience, vanilla Emacs lacks many convenient commands (or at least 
some efficient key bindings for available convenient commands) and some 
standard commands feel counterintuitive.  I understand that this is for 
historical reasons, and I am not complaining about it, but nonetheless 
this is the way it is.  Hence the need to spend much time configuring Emacs.

Re: Elisp addiction not as bad in light of Linux forkoholism

[Eli Zaretskii]

> From: Raffaele Ricciardi <rfflrccrd@gmail.com>
> Date: Tue, 02 Dec 2014 15:50:36 +0100
> 
> The problem is that old Emacs pros don't explain the Emacs work-flow to 
> novices and therefore novices are left to "connect the dots" on their 
> own.  When novices fail to connect some dots, they resort to configure 
> Emacs to achieve some goals in a way that they know.

That theory cannot explain how novices become "old pros".  At some
point along the time line, the Emacs workflow becomes somehow known to
yesterday's novices, and then they no longer need some or maybe most
of those customizations.  But that can't happen by itself, so
something is clearly missing in your hypothesis.

Re: Elisp addiction not as bad in light of Linux forkoholism

[Loris Bennett]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Raffaele Ricciardi <rfflrccrd@gmail.com>
>> Date: Tue, 02 Dec 2014 15:50:36 +0100
>> 
>> The problem is that old Emacs pros don't explain the Emacs work-flow to 
>> novices and therefore novices are left to "connect the dots" on their 
>> own.  When novices fail to connect some dots, they resort to configure 
>> Emacs to achieve some goals in a way that they know.
>
> That theory cannot explain how novices become "old pros".  At some
> point along the time line, the Emacs workflow becomes somehow known to
> yesterday's novices, and then they no longer need some or maybe most
> of those customizations.  But that can't happen by itself, so
> something is clearly missing in your hypothesis.

Some of us just become "old novices" with two decades worth of
cargo-cult cruft in our .emacs ...

Cheers,

Loris

PS: What's "the Emacs work-flow"?  Is it anything like the Swiss Army
Knife Workflow or the Kitchen Sink Workflow?

-- 
This signature is currently under construction.

Re: Elisp addiction not as bad in light of Linux forkoholism

[Eli Zaretskii]

> From: "Loris Bennett" <loris.bennett@fu-berlin.de>
> Date: Tue, 02 Dec 2014 17:01:52 +0100
> 
> PS: What's "the Emacs work-flow"?  Is it anything like the Swiss Army
> Knife Workflow or the Kitchen Sink Workflow?

No clue.  Perhaps the OP could explain.

Re: Elisp addiction not as bad in light of Linux forkoholism

[Stefan Monnier]

> PS: What's "the Emacs work-flow"?

If you don't know yet, then you're not worthy of knowing.


        Stefan "another old novice"

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> PS: What's "the Emacs work-flow"?
>
> If you don't know yet, then you're not worthy of
> knowing.

I guess people use Emacs in very different ways. Still
there should be even bigger similarities. But it is
rather difficult to pinpoint, perhaps because there is
no other program you ever use in remotely the same
way.

If Emacs was only an editor you could compare it with
nano and say it has more features, it is more
configurable, it has specialized modes for different
code, etc. (perhaps nano has that as well?).

If Emacs was only Gnus you could compare it to
Thunderbird and - and so on.

But Emacs is all this and much more, at the same time,
with an interface that is as much the same as it can
be, for so many activities.

Perhaps this is what makes it almost hypnotic, and
part of why you can do it for many hours straight
without getting bored or mentally tired. There is just
so much to do and you yourself don't have to change
that much when you change activity, so there is no
"energy drain" resetting and preparing for something
else...

Another thing with configuration and Elisp which
hasn't been touched upon is that it is activity that
breeds more activity. Which is very good because
activity is the basis of everything. The more you do
it, the more you learn and understand, and the more
ideas what more to do you get.

You know those forums where aspiring programmers ask
for things to do, because they want to program but
they don't have any ideas what to do? Then there is
always some guy saying "a text editor" (as irony, as
that would be almost impossible for a beginner to do)
- but actually that guy could, without irony, say:
"Start configuring Emacs, and write shell functions
for the stuff you do!" If you do that, there is
*never* a lack of things to do :)

-- 
underground experts united

Re: Elisp addiction not as bad in light of Linux forkoholism

[Emanuel Berg]

Raffaele Ricciardi <rfflrccrd@gmail.com> writes:

> The problem is that old Emacs pros don't explain the
> Emacs work-flow to novices and therefore novices are
> left to "connect the dots" on their own. When
> novices fail to connect some dots, they resort to
> configure Emacs to achieve some goals in a way that
> they know.

Good point.

> Moreover, in my experience, vanilla Emacs lacks many
> convenient commands (or at least some efficient key
> bindings for available convenient commands) and some
> standard commands feel counterintuitive. I
> understand that this is for historical reasons, and
> I am not complaining about it, but nonetheless this
> is the way it is. Hence the need to spend much time
> configuring Emacs.

Right. It can be very educational to tinker with
software day in, day out, but not the whole day,
little by little. Because lots of software is
basically the same, if you understand one piece of
software, not 100% like memorizing everything, rather
the broad lines, then that understanding will be like
a window so you can understand other software as well.

That's the intellectual side to it. The emotional, or
perhaps "enjoyment" side to it is to have a system you
really like and are familiar with.

Like your post, and mine. I enjoyed reading yours and
I enjoyed writing mine. But with Outlook and Windows,
I would never do either. So the emotional side, having
it look and behave a way that is going with the flow
of your brain-waves and - I don't know - muscle-memory
and all - that should never be underestimated.

-- 
underground experts united