Re: Apologia for bzr

Re: Apologia for bzr

[Alexander Meesters]

Dear Dr. Stallman,

To answer your question:"Do beginners typically run Emacs under a
graphical window system?", it seems so. I myself am a recent Emacs
adaptee(its been 3 days now), since i finaly decided to learn to program
in C(comming from a php and python background).

From what i picked up on the several IRC chatrooms i visit, the
generally use is under a graphical window system, although this would be
hardly representable for the masses, i didnt even know Emacs can work
without a GUI, most "Getting started with Emacs" tutorial that are
scattered throughout the web only cover the Emacs GUI.

Sincerely,

Alexander "Cyberwaste" Meesters.
PS) thank you for all the beautifull things you have given us.

bzr is dying; Emacs needs to move

[Eric S. Raymond]

I am posting this because I think it is my duty as a topic expert in
version-control systems and the surrounding tools to do so, not because
I have any desire to be in the argument that is certain to ensue.

The bzr version control system is dying; by most measures it is
already moribund.  The dev list has flatlined, most of Canonical's
in-house projects have abandoned bzr for git, and one of its senior
developers has written a remarkably candid assessment of why bzr
failed:

http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html

I urge all Emacs developers to read this, then sleep on it, then read
it again - not least because I think Emacs development has fallen into
some of the same traps the author decribes.  But *that* is a discussion for
another day; the conversation we need to have now is about escaping
the gravitational pull of bzr's failure.

In theory, that failure need not affect us at all providing the bzr
codebase is sufficently mature to continue in use as a production
tool.  I judge that, in fact, it *is* sufficiently mature.

In practice, I judge that sticking with bzr would have social and
signaling effects damaging to Emacs's prospects. Sticking to a 
moribund version-control system will compound and exacerbate the 
project's difficulty in attracting new talent.

The uncomfortable truth is that many younger hackers already think
Emacs is a dinosaur - difficult, bulky, armor-plated, and generally
stuck in the last century. If we're going to fight off that image, we
cannot afford to make or adhere to choices that further cast the
project as crusty, insular, and backward-looking.

As of right about now, continuing with bzr is such a choice.  We'll
lose potential recruits, not merely because bzr has a learning cost
but because crusty, insular, etc.  The opportunity cost of not getting
out will only rise with time.

git won the mindshare war.  I regret this - I would have preferred
Mercurial, but it too is not looking real healthy these days.  I have
made my peace with git's victory and switched.  I urge the Emacs
project to do likewise.

I can be technical lead on the migration - as the author of
reposurgeon I have the skills and experience for that (I recently
moved GNU troff from CVS to git). But the project leadership needs
to make the go decision first.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.

Re: bzr is dying; Emacs needs to move

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I don't insist that Emacs should stay with bzr.  I chose to support
bzr because it was still a contender at the time.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

PROPOSAL: Move to git, now that bzr is no longer a req.

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>I don't insist that Emacs should stay with bzr.  I chose to support
>bzr because it was still a contender at the time.

Now that RMS has dropped the bzr requirement, I propose we move to git.
ESR has graciously offered to be technical lead for such a migration.

Does anyone think we should stay on bzr, or choose a VCS other than git?

If there is significant support for a different system, then I guess we
should hold a poll.  But my (tentative) expectation is that there will
be a pretty clear overall group preference for git -- I'm mainly posting
this so there's a place for people to follow up to express their
preference, so we can quickly get a sense of whether moving to git is
the obvious call for the group as a whole, not just for those of us who
have been been expressing that preference for some time.

-Karl

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Thu, 02 Jan 2014 09:41:06 -0600
> 
> Now that RMS has dropped the bzr requirement, I propose we move to git.
> ESR has graciously offered to be technical lead for such a migration.

As Andreas points out, there's nothing to migrate, except ourselves.

> Does anyone think we should stay on bzr, or choose a VCS other than git?

I love bzr and hate git.  I hope Emacs will not switch from bzr in my
lifetime, not to git anyway.

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> lifetime, not to git anyway.

I can understand hating git; the UI is pretty nasty, and there is at least
a colorable argument that containerlessness is a bug.  I use git in spite 
of its defects, not because I don't know they're there.

I don't understand loving bzr; my experiences with it have been unpleasant. 
I would be interested to hear your apologia for it.  

Mind you, I think opposing git adoption is like trying to stop the tide
from coming in, at this point (and have my own mixed feelings about that).
But I am genuinely curious about your reasons.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 12:28:04 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > I love bzr and hate git.  I hope Emacs will not switch from bzr in my
> > lifetime, not to git anyway.
> 
> I can understand hating git; the UI is pretty nasty, and there is at least
> a colorable argument that containerlessness is a bug.  I use git in spite 
> of its defects, not because I don't know they're there.

I use git, too.  That's why I hate it, not because I've read about it
in some blog.

> I don't understand loving bzr; my experiences with it have been unpleasant. 
> I would be interested to hear your apologia for it.  

I don't know where to begin.  In a nutshell, it is simple to use, yet
powerful enough to give me several important workflows, and an easy
way to fix any mistakes I happen to make (although lately there are
almost none).  It works on Unix and on Windows alike, and does both
seamlessly.  The UI is orders of magnitude simpler and easier to grasp
that that of git.  The documentation, while it can use some serious
improvement, is nevertheless orders of magnitude more clear than git's
man pages, which seem to have been written by some math professor who
can produce rigorous formal papers, but doesn't have the slightest
idea how to write useful and efficient user documentation.

And of course, everything is similar but subtly different from bzr, to
the point that I need to consult my notes on every step, for fear of
making a mistake.  The switch from CVS to bzr was very simple by
comparison, even though the d in dVCS did require some mind shift.

> Mind you, I think opposing git adoption is like trying to stop the tide
> from coming in, at this point (and have my own mixed feelings about that).

You probably don't know me well enough, if you are surprised by my
trying to stop the tide.

Apologia for bzr

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I don't know where to begin.  In a nutshell, [bzr] is simple to use, yet
> powerful enough to give me several important workflows, and an easy
> way to fix any mistakes I happen to make (although lately there are
> almost none).

git is powerful, and what it can do it can also undo; that part is a wash.
I don't think it is in any danger of being described as simple to use, though;
nobody but the blindest git fanboys are going to argue with you on that.

>                It works on Unix and on Windows alike, and does both
> seamlessly.

Not any more.  One of the reported symptoms of decline is that Windows 
support has fallen by the wayside.  I don't care about this, so I
haven't checked myself.

>       The UI is orders of magnitude simpler and easier to grasp
> that that of git.

Agreed, from my experience.  Mercurial's UI is better, too.

>                  The documentation, while it can use some serious
> improvement, is nevertheless orders of magnitude more clear than git's
> man pages, which seem to have been written by some math professor who
> can produce rigorous formal papers, but doesn't have the slightest
> idea how to write useful and efficient user documentation.

I think this is a bit unfair.  In my experience the git pages are
terrible as tutorials, but pretty clear as references once you have an
overall grasp of how things work.  They could easily be far, *far* worse.

And I have to say my experience with bzr documentation was little better.
Less forbiddingly dry and formal, perhaps, but with the same property that
you have to get your head inside bzr's assumptions before much of it makes
sense.  This may be unavoidable; DVCSes are not simple creatures.

> And of course, everything is similar but subtly different from bzr, to
> the point that I need to consult my notes on every step, for fear of
> making a mistake.  The switch from CVS to bzr was very simple by
> comparison, even though the d in dVCS did require some mind shift.

Fair enough.  Similar enough to trip you up is often worse than very different.
I don't think this counts as an argument for bzr, though; if you has absorbed
git first you might have sumilar feelings in an opposite direction.

> > Mind you, I think opposing git adoption is like trying to stop the tide
> > from coming in, at this point (and have my own mixed feelings about that).
> 
> You probably don't know me well enough, if you are surprised by my
> trying to stop the tide.

I don't know you personally, but we've been moving in the same circles
for enough decades that I'm...not very surprised.

If it helps any, I'm sympathetic.  I still wish Mercurial had won.  It
didn't.  I have faced reality and coped.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 13:34:32 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> >                It works on Unix and on Windows alike, and does both
> > seamlessly.
> 
> Not any more.  One of the reported symptoms of decline is that Windows 
> support has fallen by the wayside.  I don't care about this, so I
> haven't checked myself.

Don't believe it.  I use bzr on Windows all the time.

> >                  The documentation, while it can use some serious
> > improvement, is nevertheless orders of magnitude more clear than git's
> > man pages, which seem to have been written by some math professor who
> > can produce rigorous formal papers, but doesn't have the slightest
> > idea how to write useful and efficient user documentation.
> 
> I think this is a bit unfair.  In my experience the git pages are
> terrible as tutorials, but pretty clear as references once you have an
> overall grasp of how things work.

They are impenetrable.  The very first words will get you in a "WTF?"
mode.  Just try to read the first sentences of any random man page
through a newbie's eyes.  No term is ever explained before used -- do
these guys even understand what it means to _explain_ things?  It's as
if you need to learn a whole new language.  Here, a typical example
from git-commit:

  DESCRIPTION 

  Stores the current contents of the index in a new commit along with
   a log message from the user describing the changes.

Huh?  "Contents of the index"?  I used to know what commit was, now I
don't.

> They could easily be far, *far* worse.

Yeah, but that's hardly a compliment.

Re: Apologia for bzr

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > Date: Thu, 2 Jan 2014 13:34:32 -0500
> > From: "Eric S. Raymond" <esr@thyrsus.com>
> > Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> > 
> > >                It works on Unix and on Windows alike, and does both
> > > seamlessly.
> > 
> > Not any more.  One of the reported symptoms of decline is that Windows 
> > support has fallen by the wayside.  I don't care about this, so I
> > haven't checked myself.
> 
> Don't believe it.  I use bzr on Windows all the time.

In newer versions, I mean.
 
> They are impenetrable.

I didn't find them so.  Tough, but not impemetrable.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 15:51:54 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > > Date: Thu, 2 Jan 2014 13:34:32 -0500
> > > From: "Eric S. Raymond" <esr@thyrsus.com>
> > > Cc: kfogel@red-bean.com, emacs-devel@gnu.org
> > > 
> > > >                It works on Unix and on Windows alike, and does both
> > > > seamlessly.
> > > 
> > > Not any more.  One of the reported symptoms of decline is that Windows 
> > > support has fallen by the wayside.  I don't care about this, so I
> > > haven't checked myself.
> > 
> > Don't believe it.  I use bzr on Windows all the time.
> 
> In newer versions, I mean.

Yes, I mean that too.  Mine is 2.6.

Re: Apologia for bzr

[Juanma Barranquero]

On Thu, Jan 2, 2014 at 10:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Yes, I mean that too.  Mine is 2.6.

2.6b1, unless you build your own Windows binary. Neither the 2.6b2 nor
the official 2.6 releases have been distributed as Windows binaries.
As you well know.

I happen to like Bazaar and dislike git, but I don't think supporting
Windows is a strong point of the Bazaar project (nor git's, truth be
told).

    J

Re: Apologia for bzr

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Thu, 2 Jan 2014 22:15:58 +0100
> Cc: Eric Raymond <esr@thyrsus.com>, Karl Fogel <kfogel@red-bean.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Thu, Jan 2, 2014 at 10:03 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Yes, I mean that too.  Mine is 2.6.
> 
> 2.6b1, unless you build your own Windows binary.

Yes, but so what? there were no changes since that beta.

> I don't think supporting Windows is a strong point of the Bazaar
> project

It is for me.

Re: Apologia for bzr

[Juanma Barranquero]

On Fri, Jan 3, 2014 at 8:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Yes, but so what? there were no changes since that beta.

And yet, there's been no one able or willing to just change the version string
to 2.6, build for Windows and upload the tarball to the
official site. For a couple years, at least (I'm talking about 2.6b2
and 2.6 here). Which speaks volumes of the *commitment* to Windows...
or perhaps of the vitality of the Bazaar project as a whole.

   J

Re: Apologia for bzr

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 3 Jan 2014 12:11:36 +0100
> Cc: Eric Raymond <esr@thyrsus.com>, Karl Fogel <kfogel@red-bean.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Jan 3, 2014 at 8:47 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Yes, but so what? there were no changes since that beta.
> 
> And yet, there's been no one able or willing to just change the version string
> to 2.6, build for Windows and upload the tarball to the
> official site. For a couple years, at least (I'm talking about 2.6b2
> and 2.6 here). Which speaks volumes of the *commitment* to Windows...
> or perhaps of the vitality of the Bazaar project as a whole.

When no new versions of bzr come out, the fact that no one produces
Windows installers is a moot point.

Anyway, the commitment to Windows is of no interest to me; the fact
that it works well there is.

Re: Apologia for bzr

[Juanma Barranquero]

On Fri, Jan 3, 2014 at 12:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> When no new versions of bzr come out, the fact that no one produces
> Windows installers is a moot point.

But, there's been a new version. It's called 2.6. It has no official
Windows build. You know 2.6b1 is, to all practical effects, identical;
I know it, too. But a random prospective user who hits the Bazaar
homepage for the first time does not. How hard is (for people used to
it and with the building environment already set up) to fire the
building process and pack a new release?

> Anyway, the commitment to Windows is of no interest to me;

Perhaps not to you, but for me, it is because I fear the time when a
serious bug raises its ugly head and no one is willing to fix it, or
fixes it and nobody bothers to update the Windows binaries.

As I said, I like Bazaar much, *much* more than git. But it is hard to
shake the feeling that it currently stinks of death.

    J

Re: Apologia for bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Don't believe it.  I use bzr on Windows all the time.
>> 
>> In newer versions, I mean.
>
> Yes, I mean that too.  Mine is 2.6.

My recalls from the last time I browsed the bzr mailing lists (possibly
two years ago) is that the few remaining maintainers are not terribly
interested on enhancing bzr (for any platform) and simply unconcerned
about Windows support.

Re: Apologia for bzr

[Toby Cubitt]

On Thu, Jan 02, 2014 at 10:44:03PM +0200, Eli Zaretskii wrote:
> > >                  The documentation, while it can use some serious
> > > improvement, is nevertheless orders of magnitude more clear than git's
> > > man pages, which seem to have been written by some math professor who
> > > can produce rigorous formal papers, but doesn't have the slightest
> > > idea how to write useful and efficient user documentation.
> > 
> > I think this is a bit unfair.  In my experience the git pages are
> > terrible as tutorials, but pretty clear as references once you have an
> > overall grasp of how things work.
> 
> They are impenetrable.  The very first words will get you in a "WTF?"
> mode.  Just try to read the first sentences of any random man page
> through a newbie's eyes.  No term is ever explained before used -- do
> these guys even understand what it means to _explain_ things?  It's as
> if you need to learn a whole new language.

This is the Emacs mailing list I'm on, right? Emacs of "find" a file to
open it, files live in "buffers", "windows" aren't windows but "frames"
are, "kill" to cut and "yank" to paste fame? ;-)

> Here, a typical example from git-commit:
> 
>   DESCRIPTION 
> 
>   Stores the current contents of the index in a new commit along with
>    a log message from the user describing the changes.
> 
> Huh?  "Contents of the index"?  I used to know what commit was, now I
> don't.

The same could be said of most unix man pages. Good man pages aren't
supposed to be tutorials. They're supposed to be reference manuals, for
looking up a terse and comprehensive description of usage, options,
switches, flags etc. Or at least, that's how I've always understood (and
used) them.

And there *are* decent git tutorials available from the official web site
that explain things without assuming you already know how git works
(e.g. http://git-scm.com/book isn't bad).

I'm not a great fan of the git UI. But complaining that the git man pages
are precisely what man pages are supposed to be is a little disingenuous.

Or maybe my problem is I'm a maths professor :)

Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 21:14:52 +0000
> From: Toby Cubitt <tsc25@cantab.net>
> Cc: esr@thyrsus.com, kfogel@red-bean.com, emacs-devel@gnu.org
> 
> > They are impenetrable.  The very first words will get you in a "WTF?"
> > mode.  Just try to read the first sentences of any random man page
> > through a newbie's eyes.  No term is ever explained before used -- do
> > these guys even understand what it means to _explain_ things?  It's as
> > if you need to learn a whole new language.
> 
> This is the Emacs mailing list I'm on, right? Emacs of "find" a file to
> open it, files live in "buffers", "windows" aren't windows but "frames"
> are, "kill" to cut and "yank" to paste fame? ;-)

Indeed, and we all know that these are obstacles to newbies, so wise
people (and git development is full of them, right?) shouldn't have
gone that way.  At least in Emacs we have an excuse that the bulk of
the terminology developed when no other software provided any similar
features; there's no such excuse for git (or bzr or hg).

Anyway, there's a big difference here: in Emacs documentation, every
term is explained before it is used, and rarely used terms have
cross-references to where they are described.

> > Here, a typical example from git-commit:
> > 
> >   DESCRIPTION 
> > 
> >   Stores the current contents of the index in a new commit along with
> >    a log message from the user describing the changes.
> > 
> > Huh?  "Contents of the index"?  I used to know what commit was, now I
> > don't.
> 
> The same could be said of most unix man pages.

I'm reading Unix man pages for many years, and I must disagree: they
are generally quite self-explanatory.  Git is exceptional in this
regard.

> Good man pages aren't supposed to be tutorials. They're supposed to
> be reference manuals, for looking up a terse and comprehensive
> description of usage, options, switches, flags etc. Or at least,
> that's how I've always understood (and used) them.

You are missing the point: I didn't want a tutorial.  I use VCSes for
many years, and dVCSes for some; I already know what it means to
commit a changeset and what is the basic workflow of using a dVCS.  I
wanted a "terse and comprehensive description" of the git's commit
command, including all of its options.  But when I read the above
"Description" line, I start to question the correctness of my notion
of what a commit is.  Here, look at these "descriptions" of options:

  -a 
  --all 
    Tell the command to automatically stage files that have been
    modified and deleted, but new files you have not told Git about are
    not affected.

If you don't already know what is "staging", you will never understand
that this is one of the most important and useful options.  Also,
"haven't told Git about new files" fails to mention "git add".  Once
I've managed to grasp all that, I've made an alias for "commit -a",
because that's what I almost always want.  (And why isn't that the
default, dammit?)

  --reuse-message=<commit> 
    Take an existing commit object, and reuse the log message and the
    authorship information (including the timestamp) when creating the
    commit.

"Commit object"? what's that?  There's no reference to where this is
explained; without such a reference, this "description" is
non-instrumental, and thus useless.  This problem is, of course,
common to all the other options that refer to a "commit object", of
which there are many on this page.

  --allow-empty 
    Usually recording a commit that has the exact same tree as its
    sole parent commit is a mistake, and the command prevents you from
    making such a commit. This option bypasses the safety, and is
    primarily for use by foreign SCM interface scripts.

"Recording a commit"? what's that?  And is "commit that has the exact
same tree as its sole parent commit" a complicated way of saying "no
changes since the last commit", or is there some important subtlety
here that I'm missing?  Even bzr's commit docs does much better:

  --unchanged   Commit even if nothing has changed.

Etc., etc. -- I could go for hours on end with these examples.

Mind you, I have this and other important git man pages open on my
desktop at all times, and I consult them all the time.  And I still
don't get some of the details.

And if you are still not convinced, let me show you what this
"documentation" style would mean if the Emacs manual would use it.
Let's take for example what the C-f key does in Emacs.  You think you
know what it does?  Here's what the Emacs manual says:

  `C-f'
       Move forward one character (`forward-char').

Simple, self-explanatory, and concise.  Also inaccurate, because
that's not what really happens when you press C-f.  Here's what does
happen:

  `C-f'
       Move forward to the next visible buffer position, skipping any
       invisible text and lines hidden by selective display.  The next
       redisplay cycle will display the cursor on the grapheme cluster
       to which the new buffer position belongs.  If the new buffer
       position is the newline character, display the cursor on the
       empty glyph beyond the end of the line.  If the new buffer
       position has a display property defined for it, display the
       cursor on the first glyph produced from that display property,
       or on the glyph that has the 'cursor' property defined for it.

This is the accurate description of what C-f does, complete with
references to about half a dozen of highly technical terms that I
didn't bother to explain.  I managed to be an efficient and happy
Emacs user and hacker for 15 years without knowing most of this.  It's
not until I started seriously hacking the display engine 5 years ago
that I became aware of all those details -- because I needed them then
to be able to make the changes in the Emacs display.

> And there *are* decent git tutorials available from the official web site
> that explain things without assuming you already know how git works
> (e.g. http://git-scm.com/book isn't bad).

I DON'T WANT TUTORIALS, I've already read them.  I want some decent
reference documentation.  I just don't want all the details about
what's going on under the hood crammed down my throat every time I
want to learn what some option does, or find an option that does what
I need to accomplish.

> Or maybe my problem is I'm a maths professor :)

I didn't say that ;-)

Re: Apologia for bzr

[Yuri Khan]

On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> If you don't already know what is "staging", you will never understand
> that this is one of the most important and useful options.  Also,
> "haven't told Git about new files" fails to mention "git add".  Once
> I've managed to grasp all that, I've made an alias for "commit -a",
> because that's what I almost always want.  (And why isn't that the
> default, dammit?)

Because staging is a key concept in git and it enables a whole lot of
useful workflows. E.g. you can work all day and half the next day on a
feature, making small formatting changes and fix coding style
violations on your way as you spot them, then fire up a commit tool
and make three commits, one for trivial formatting changes, another
for coding style fixes, and a third one with the feature you actually
worked on.

Without staging, you would have to look at the diff, back up and
revert some changes so that the working directory looks the way you
want for one commit, then the other, then the next one. Or you would
hold off fixing small things until you have committed the feature, and
risk forgetting to do them.

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Fri, 3 Jan 2014 16:21:26 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Toby Cubitt <toby-dated-1389906911.cc0ede@dr-qubit.org>, 
> 	Eric Raymond <esr@thyrsus.com>, kfogel@red-bean.com, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > If you don't already know what is "staging", you will never understand
> > that this is one of the most important and useful options.  Also,
> > "haven't told Git about new files" fails to mention "git add".  Once
> > I've managed to grasp all that, I've made an alias for "commit -a",
> > because that's what I almost always want.  (And why isn't that the
> > default, dammit?)
> 
> Because staging is a key concept in git and it enables a whole lot of
> useful workflows.

I know that.  Don't take my questions as indications that I'm
unfamiliar with basic git terminology (I was once, but no more).

> E.g. you can work all day and half the next day on a
> feature, making small formatting changes and fix coding style
> violations on your way as you spot them, then fire up a commit tool
> and make three commits, one for trivial formatting changes, another
> for coding style fixes, and a third one with the feature you actually
> worked on.

I was talking about the defaults.  For the defaults, the important
question is what would J. R. Hacker want in most of his commits.  It
seems to me that occasional contributors to projects (as opposed to
their core developers) will seldom if ever get to the complicated
workflows you describe.  It's definitely true for me in a couple of
projects in which I'm involved (not Emacs, obviously).

> Without staging, you would have to look at the diff, back up and
> revert some changes so that the working directory looks the way you
> want for one commit, then the other, then the next one. Or you would
> hold off fixing small things until you have committed the feature, and
> risk forgetting to do them.

Well, let's begin by agreeing that what you described is just bad
habit: you should commit very frequently, and so seldom if ever get to
the point where you have hacked for a day and a half without a single
commit.

Re: Apologia for bzr

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > At least in Emacs we have an excuse that the bulk of the
 > terminology developed when no other software provided any similar
 > features; there's no such excuse for git (or bzr or hg).

You're wrong about git, you're arguably right about bzr and hg.

Git is fundamentally different from bzr and hg, almost as different as
it is from CVS and RCS.  Git is designed for use cases like "git
filter-branch", it's easy enough to implement it as a shell script
(though it would be slow), and probably it was prototyped that way
(although I would write the prototype in Lisp, not shell).  I really
wouldn't want to try to do that in hg or bzr: although it could be
done, it would be unusably slow (because they don't have a separate
index, so the work has to be done in-tree-on-disk, rather than only on
metadata in memory).

 > Anyway, there's a big difference here: in Emacs documentation,
 > every term is explained before it is used, and rarely used terms
 > have cross-references to where they are described.

I bet you can dip into any number of Info nodes where the terms
"buffer" and "window" are used without definition.  The git "index" is
equally fundamental to git.  It's what makes things like "git reset"
make sense.  It's what explains the sometimes disconcerting behavior
of git diff with respect to "git add"ed files.  It's what makes
staging workflows (which some people love even if you can't figure out
why they could love them :-) possible.

 > > > Here, a typical example from git-commit:
 > > > 
 > > >   DESCRIPTION 
 > > > 
 > > >   Stores the current contents of the index in a new commit along with
 > > >    a log message from the user describing the changes.
 > > > 
 > > > Huh?  "Contents of the index"?  I used to know what commit was, now I
 > > > don't.

Sure you do; commit hasn't changed.  What you now know is what the
index is: a data structure that contains the same information as a
commit, but isn't a commit and isn't a working tree, either.  It has
an independent life of its own.  Implicitly, it is volatile, and "git
commit" makes a persistent record of its current state.

Of course hg and bzr use indexes, too, but they're not exposed to the
user: they only exist during the process of committing.

 > You are missing the point: I didn't want a tutorial.  I use VCSes for
 > many years, and dVCSes for some; I already know what it means to
 > commit a changeset and what is the basic workflow of using a dVCS.

But I think you've misstated the case here.  Development has
workflows, and dVCS usage is adapted to them.  It doesn't make sense
to talk about "*the* basic workflow of using a dVCS".  You're actually
talking about *your* basic workflow, and how you use a dVCS in that
workflow.  Other people's workflows vary wildly, and from the point of
view of dVCS usage, they're just as basic.

 > "Recording a commit"? what's that?  And is "commit that has the exact
 > same tree as its sole parent commit" a complicated way of saying "no
 > changes since the last commit", or is there some important subtlety
 > here that I'm missing?

It's probably not important to you, so I won't go into detail, but
there are several subtleties that are missing from the simple
expression "no changes since the last commit".  But this is again
missing an important point about how git is different:

 > Even bzr's commit docs does much better:
 > 
 >   --unchanged   Commit even if nothing has changed.

This makes a lot of sense in Bazaar, because Bazaar makes it hard to
work nonlinearly without using multiple workspaces.  Nonlinear
workflows in a single repo/workspace are what git is designed for.  In
a nonlinear workflow, "nothing has changed" is meaningless until you
answer the question "since *when*?"  "The parent commit" is the
precise and meaningful answer.

 > I want some decent reference documentation.

AFAICT, you want your dVCS to be Bazaar.  Nothing wrong with that
(while I really dislike bzr, I don't think it's dead, at least not
yet, and that dislike is a personal thing, no reason why you should
change your mind).  But the overwhelming majority of posters (and I
suspect that means the majority of Emacs developers) want git, and git
is not, will not be, and should not be, Bazaar.  Sorry!

Re: Apologia for bzr

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Toby Cubitt <toby-dated-1389906911.cc0ede@dr-qubit.org>,
>     esr@thyrsus.com,
>     kfogel@red-bean.com,
>     emacs-devel@gnu.org
> Date: Sat, 04 Jan 2014 05:34:06 +0900
> 
> Eli Zaretskii writes:
> 
>  > At least in Emacs we have an excuse that the bulk of the
>  > terminology developed when no other software provided any similar
>  > features; there's no such excuse for git (or bzr or hg).
> 
> You're wrong about git, you're arguably right about bzr and hg.

What, git was the first VCS, and needed to invent a new terminology?

> Git is fundamentally different from bzr and hg, almost as different as
> it is from CVS and RCS.  Git is designed for use cases like "git
> filter-branch", it's easy enough to implement it as a shell script
> (though it would be slow), and probably it was prototyped that way
> (although I would write the prototype in Lisp, not shell).  I really
> wouldn't want to try to do that in hg or bzr: although it could be
> done, it would be unusably slow (because they don't have a separate
> index, so the work has to be done in-tree-on-disk, rather than only on
> metadata in memory).

What does this have to do with clear and comprehensible documentation?

>  > Anyway, there's a big difference here: in Emacs documentation,
>  > every term is explained before it is used, and rarely used terms
>  > have cross-references to where they are described.
> 
> I bet you can dip into any number of Info nodes where the terms
> "buffer" and "window" are used without definition.

I said "rarely used terms".  Frequently used terms need to be
understood in advance, by reading the preceding chapters.

In any case, buffer and window can be intuitively understood, much
more than "index" and "staging".

> The git "index" is equally fundamental to git.

But there is a way to explain what a commit does without ever
mentioning the index, certainly not in the sentence that _defines_
what a commit is.

>  > > >   Stores the current contents of the index in a new commit along with
>  > > >    a log message from the user describing the changes.
>  > > > 
>  > > > Huh?  "Contents of the index"?  I used to know what commit was, now I
>  > > > don't.
> 
> Sure you do; commit hasn't changed.  What you now know is what the
> index is: a data structure that contains the same information as a
> commit, but isn't a commit and isn't a working tree, either.

No, I don't know any of this, because it wasn't explained, not even in
a few words that would help me make it past the obstacle.

>  > You are missing the point: I didn't want a tutorial.  I use VCSes for
>  > many years, and dVCSes for some; I already know what it means to
>  > commit a changeset and what is the basic workflow of using a dVCS.
> 
> But I think you've misstated the case here.  Development has
> workflows, and dVCS usage is adapted to them.  It doesn't make sense
> to talk about "*the* basic workflow of using a dVCS".  You're actually
> talking about *your* basic workflow, and how you use a dVCS in that
> workflow.

No, I'm talking about *the* basic workflow: make changes, then commit
them.  Tutorials seldom go beyond that.

>  > "Recording a commit"? what's that?  And is "commit that has the exact
>  > same tree as its sole parent commit" a complicated way of saying "no
>  > changes since the last commit", or is there some important subtlety
>  > here that I'm missing?
> 
> It's probably not important to you, so I won't go into detail, but
> there are several subtleties that are missing from the simple
> expression "no changes since the last commit".

As there were a few subtleties missing from my mock description of
C-f.

>  >   --unchanged   Commit even if nothing has changed.
> 
> This makes a lot of sense in Bazaar, because Bazaar makes it hard to
> work nonlinearly without using multiple workspaces.

I was talking about clear documentation, not about the differences
between git and bzr.

>  > I want some decent reference documentation.
> 
> AFAICT, you want your dVCS to be Bazaar.

It doesn't matter what I want in this case, we all know what I will
get, right?  Since that's what I will get, I want its documentation to
be helpful.  Please don't misrepresent what I wrote by turning it into
another "git is more powerful than bzr" thread.  That is not what I
was talking about.

Anyway, I'm beginning to regret that I answered esr's question.  I
should have known what kind of "tide" will be unleashed on me.

Re: Apologia for bzr

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > Eli Zaretskii writes:
 > > 
 > >  > At least in Emacs we have an excuse that the bulk of the
 > >  > terminology developed when no other software provided any similar
 > >  > features; there's no such excuse for git (or bzr or hg).

And I replied:

 > > You're wrong about git, you're arguably right about bzr and hg.
 > 
 > What, git was the first VCS, and needed to invent a new terminology?

Not the first VCS, but certainly a leader in the generation of VCSes
first to provide the features that got new terminology (index, fetch,
pull, push).  For older features (such as commit, diff, and merge) it
uses the traditional terminology.

 > > Git is fundamentally different from bzr and hg, almost as
 > > different as it is from CVS and RCS.  [...]

 > What does this have to do with clear and comprehensible
 > documentation?

dVCS, being fundamentally different from cVCS, needs new terminology
(eg, at least one of the three concepts "commit", "push", and "commit
and push" needs a term not used in cVCS).  Similarly, git, being
fundamentally different from bzr and hg, *needs* more new terminology
than they do, specifically "index" and "reset".  Inventing it was not
avoidable.  The rest of that paragraph was justification for the claim
that git is different.

 > I said "rarely used terms".  Frequently used terms need to be
 > understood in advance, by reading the preceding chapters.

"Index" and "commit object" are used frequently in git documentation,
although perhaps not in the parts you have read.

 > In any case, buffer and window can be intuitively understood, much
 > more than "index" and "staging".

In fact, some people find "buffer" and "window" very unintuitive (they
don't know what a "buffer" is, they think they're looking at a "file"
or "document", and "window" means a GUI object, not a subdivision of
the GUI object).  Others (me, and at least one other person has
testified to finding "staging" very intuitive) find "staging" and
"index" quite intuitive, thank you very much.

 > > The git "index" is equally fundamental to git.
 > 
 > But there is a way to explain what a commit does without ever
 > mentioning the index, certainly not in the sentence that _defines_
 > what a commit is.

Sure, but to define commit in git, it also needs to describe what a
commit object is, which is (basically) a file containing a copy of the
index.  If you know what the index is, then you know what a commit
object is, and then you know what a commit is.  Understanding this is
important to understanding the performance characteristics of git, as
well as the operation of some features not available in other dVCSes.

 > > Sure you do; commit hasn't changed.  What you now know is what the
 > > index is: a data structure that contains the same information as a
 > > commit, but isn't a commit and isn't a working tree, either.
 > 
 > No, I don't know any of this, because it wasn't explained, not even in
 > a few words that would help me make it past the obstacle.

git help glossary

I agree that's inconvenient compared to an Info link, and that the
current version of the top-level git man page (which just lists the
other man pages) is pretty hideous -- IMO it ought to contain about half
the material in the glossary plus a description of the structure of the
git object database with a few key terms explained with reference to
the object database operations they perform.

 > No, I'm talking about *the* basic workflow: make changes, then commit
 > them.  Tutorials seldom go beyond that.

C'mon, I'm a coauthor of BzrForEmacsDevs, and did my homework (reading
other tutorials).  You should be able to guess that I know better than
that.  But taking your claim at face value: that requires no reading
of manpages to accomplish in git if you've used any VCS (including
RCS) before.  So you're just being contentious here.

You only run into problems by pretending that git is CVS or bzr if you
use facilities like reset (not possible in any other VCS, you have to
revert or commit -- both available in git) and rebase (way beyond your
"the *basic* workflow").

 > >  >   --unchanged   Commit even if nothing has changed.
 > > 
 > > This makes a lot of sense in Bazaar, because Bazaar makes it hard to
 > > work nonlinearly without using multiple workspaces.
 > 
 > I was talking about clear documentation, not about the differences
 > between git and bzr.

git documentation is *clear*[1] if you start by understanding how
git's purpose and implementation differs from other VCSes.  It's only
if you try to force it into your preconception of what a (d)VCS should
be that it becomes unclear.  *This is precisely why many people have
trouble grokking Emacs* -- they try to think about it as something
familiar like a wordprocessor or Notepad or a web browser, and when it
violates their preconceptions, they turn away from it in disgust.

 > >  > I want some decent reference documentation.
 > > 
 > > AFAICT, you want your dVCS to be Bazaar.
 > 
 > It doesn't matter what I want in this case, we all know what I will
 > get, right?

Now that Stefan has spoken, yes, I think we do know.  I'm genuinely
sorry for the folks who definitely prefer bzr (of whom Stefan is one,
of course).  It's a damn shame that Shuttleworth pissed off Tom Lord
-- who decided quite early on that the git object data base was the
way to go, and completely rewrote Arch/tla to use it in his
never-published "revc" aka Arch-ng -- and that the Bazaar developers
never came to the conclusion Tom did.

 > Since that's what I will get, I want its documentation to be
 > helpful.

Well, documentation can't help you if you won't help yourself.  Those
who find the git documentation completely unintelligible are going to
have to start by abandoning the idea that git is a poor implementation
of Bazaar.  (Certainly, it is, but that's not helpful in understanding
git or its documentation.)

 > Please don't misrepresent what I wrote by turning it into another
 > "git is more powerful than bzr" thread.  That is not what I was
 > talking about.

Nor is it what I was talking about.  If you want to make suggestions
that will improve git documentation[2], you are going to need to
accept that although overall it sucks, much of it is already written
in an appropriate fashion.  It's possible to discuss whether the word
"index" needs to be mentioned in the brief description of "git
commit"; although the reason for doing so I presented above is valid,
on balance it might not be the best brief description.  But effective
use of git (including understanding what "gurus" are recommending to
get a novice out of a wedge) requires the concepts of "index" and
"commit object".

The fact that bzr doesn't have that concept doesn't mean it's
unnecessary in git documentation, only that people who want git to be
bzr will think it's unnecessary.

 > Anyway, I'm beginning to regret that I answered esr's question.  I
 > should have known what kind of "tide" will be unleashed on me.

Again, you're mistaking what I'm talking about.  I'm also interested
in how to make git's documentation more useful to Emacs devs who don't
like git.

Funding from ORA or not, I'm thinking about taking the git docs and
reorganizing and supplementing them the way Nye et al did for the MIT
X docs.  But if you're going to maintain the attitude that the things
in git that aren't in bzr should be moved to appendices so you don't
need to learn about them, I'm not going to bother continuing to think
about that.

Footnotes: 
[1]  I've already acknowledged the poor organization.

[2]  Maybe Tim O'Reilly will recruit somebody to write the Git Version
Control System Series, or the Git: Essential Reference.

Re: Apologia for bzr

[Florian Weimer]

* Stephen J. Turnbull:

> Not the first VCS, but certainly a leader in the generation of VCSes
> first to provide the features that got new terminology (index, fetch,
> pull, push).  For older features (such as commit, diff, and merge) it
> uses the traditional terminology.

"pull" and "push" came from Bitkeeper (like "clone"), so those were
existing terminology as well.  "fetch" might have been new, but many
users don't need it.

"git-update-cache" for constructing commits was certainly new.  I
think even today, the concept of a persistent staging area for commits
which can be edited by the user (and from within shell scripts) is
unique to git, and "git add" behaves differently from other systems:
git will not automatically make changes part of a commit even if the
file is being tracked by version control.

RE: Apologia for bzr

[Drew Adams]

>> Anyway, there's a big difference here: in Emacs documentation,
>> every term is explained before it is used, and rarely used terms
>> have cross-references to where they are described.
> 
> I bet you can dip into any number of Info nodes where the
> terms "buffer" and "window" are used without definition.

FWIW -

I submitted Emacs bug #16333, to request linking first
occurrences (in a node) of words that are defined in
the Glossary to their definitions.

I finally got around to doing this, in my library
info+.el.  (It could be done for vanilla Emacs too.)
___

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16333

https://www.emacswiki.org/emacs/download/info%2b.el

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    This is the Emacs mailing list I'm on, right? Emacs of "find" a file to
    open it, files live in "buffers", "windows" aren't windows but "frames"
    are, "kill" to cut and "yank" to paste fame? ;-)

Emacs did these things first, and our terminology came first.  If you
wish to complain about the use of incompatible terminology by other
systems inconvenient, you need to send your complaints to their
developers.

    The same could be said of most unix man pages. Good man pages aren't
    supposed to be tutorials.

That's true.  That's the job of a real manual.
Still, man pages should be comprehensible.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Toby Cubitt]

On Fri, Jan 03, 2014 at 09:37:16AM -0500, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     This is the Emacs mailing list I'm on, right? Emacs of "find" a file to
>     open it, files live in "buffers", "windows" aren't windows but "frames"
>     are, "kill" to cut and "yank" to paste fame? ;-)
> 
> Emacs did these things first, and our terminology came first.  If you
> wish to complain about the use of incompatible terminology by other
> systems inconvenient, you need to send your complaints to their
> developers.

Do I really need to put a humour disclaimer after ever attempt at levity?
I thought the emoticon would be sufficient indication, but apparently not <sigh>.

OK, since you seem to need one, here you go: The above comment is a
joke. I'm well aware of the history of Emacs and its terminology, I don't
have a problem with it, I'm not advocating changing it, I don't think you
or anyone else is to blame because rest of the world chose to use
different terminology, nor do I feel any need to complain to developers
of other software about that choice.

>     The same could be said of most unix man pages. Good man pages aren't
>     supposed to be tutorials.
> 
> That's true.  That's the job of a real manual.
> Still, man pages should be comprehensible.

That's true. Personally, I find them comprehensible. If someone else
finds them hard to understand, perhaps they could help to improve them?
After all, they're released under a free software license. For better or
worse, git and its sometimes idiosyncratic interface is probably here to
stay.

Best wishes,
Toby
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: tsc25@cantab.net
web:   www.dr-qubit.org

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Do I really need to put a humour disclaimer after ever attempt at
    levity?  I thought the emoticon would be sufficient indication,
    but apparently not <sigh>.

You made it very clear this was a joke, but Ha Ha does not imply there
isn't an Only Serious.  That particular joke seemed to have a real
mean criticism in it.

I'm glad to know you didn't mean it that way.

It IS unfortunate for Emacs that other subsequent popular editors
all use different terms.  That's why the joke stung -- because it
implied this was due to a mistake on our part.

But even though we did not do anything wrong, it is unfortunate for us
nonetheless.  If it is possible to change Emacs to use some standard
modern terms instead of its current terms, it might be worth doing,
even if it means a series of renaming spread over a period of years.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> But even though we did not do anything wrong, it is unfortunate for us
> nonetheless.  If it is possible to change Emacs to use some standard
> modern terms instead of its current terms, it might be worth doing,
> even if it means a series of renaming spread over a period of years.

Mostly there *aren't* any "standard modern terms", because there are
no other editors in which there is so much decoupling between the 
local equivalents of our core concepts that they need to be described
separately.

There's a parallel with git jargon here...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Lennart Borgman]

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

On Sat, Jan 4, 2014 at 9:28 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Richard Stallman <rms@gnu.org>:
> > But even though we did not do anything wrong, it is unfortunate for us
> > nonetheless.  If it is possible to change Emacs to use some standard
> > modern terms instead of its current terms, it might be worth doing,
> > even if it means a series of renaming spread over a period of years.
>
> Mostly there *aren't* any "standard modern terms", because there are
> no other editors in which there is so much decoupling between the
> local equivalents of our core concepts that they need to be described
> separately.
>
> There's a parallel with git jargon here...
>

It is very different in one way. An editor is a tool you start with. It
should be convenient for everyone. Beginners may face a high complexity and
different terms (and keyboard shortcuts) for rather familiar commands makes
it much more difficult.

The difference might seem small, but since it raises complexity for
beginners it waists time for them. Human beings (not even the best) are not
very good at logical things. Complexity comes at a cost because of our
limited working memory. (Which is just a few pieces, mostly somewhere
between 5 to 12. If I may simplify a bit.)

[-- Attachment #2: Type: text/html, Size: 2244 bytes --]

Re: Apologia for bzr

[Tom]

Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> 
> It is very different in one way. An editor is a tool you start
> with. It should be convenient for everyone. Beginners may face
> a high complexity and different terms (and keyboard shortcuts)
> for rather familiar commands makes it much more difficult.The
> difference might seem small, but since it raises complexity for
> beginners it waists time for them. 

Kill/yank comes to mind as obvious example. The copy/cut/paste
terminology is pretty much standard, so the various kill/yank
operations (kill-region, copy-region-as-kill, etc.) should 
be mapped to these terms.

Re: Apologia for bzr

[David Kastrup]

Tom <adatgyujto@gmail.com> writes:

> Lennart Borgman <lennart.borgman <at> gmail.com> writes:
>> 
>> It is very different in one way. An editor is a tool you start
>> with. It should be convenient for everyone. Beginners may face
>> a high complexity and different terms (and keyboard shortcuts)
>> for rather familiar commands makes it much more difficult.The
>> difference might seem small, but since it raises complexity for
>> beginners it waists time for them. 
>
> Kill/yank comes to mind as obvious example. The copy/cut/paste
> terminology is pretty much standard, so the various kill/yank
> operations (kill-region, copy-region-as-kill, etc.) should 
> be mapped to these terms.

The problem I see with that is that the terms are mnemonics for the
keybindings: the kill bindings contain "k", the yank bindings "y".

-- 
David Kastrup

Re: Apologia for bzr

[Lennart Borgman]

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

On Sat, Jan 4, 2014 at 8:00 PM, David Kastrup <dak@gnu.org> wrote:

> Tom <adatgyujto@gmail.com> writes:
>
> > Kill/yank comes to mind as obvious example. The copy/cut/paste
> > terminology is pretty much standard, so the various kill/yank
> > operations (kill-region, copy-region-as-kill, etc.) should
> > be mapped to these terms.
>
> The problem I see with that is that the terms are mnemonics for the
> keybindings: the kill bindings contain "k", the yank bindings "y".
>
> And (as you probably remember) the problem with that as I see it is the
key bindings. Users expect CUA. ;-)

[-- Attachment #2: Type: text/html, Size: 1524 bytes --]

Re: Apologia for bzr

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> 
> The problem I see with that is that the terms are mnemonics for the
> keybindings: the kill bindings contain "k", the yank bindings "y".
> 

Killing the region is C-w.  Not really a mnemonic. Copying a region
is M-w. Only C-y has a mnemonic binding.

But users expect C-c/v/x anyway, so why force them to learn new keys
*and* new terminology. At least the terminology could follow the 
generally accepted names (copy/paste/cut) if CUA keys cannot be 
used by default.

Re: Apologia for bzr

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Sat, Jan 4, 2014 at 9:28 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
 >> Richard Stallman <rms@gnu.org>:

 >>> But even though we did not do anything wrong, it is unfortunate
 >>> for us nonetheless.  If it is possible to change Emacs to use some
 >>> standard modern terms instead of its current terms, it might be
 >>> worth doing, even if it means a series of renaming spread over a
 >>> period of years.

I don't know if it's absolutely necessary to rename the functions,
although it probably would help many potential developers, including
many who don't have a very good grasp of English and know "cut" as a
sound that describes a computer operation that has nothing to do with
knives or card tricks.  Rewriting the tutorial might be more
appropriate.

 >> Mostly there *aren't* any "standard modern terms",

You're getting too deep here.  I'm pretty sure what's under discussion
is cut vs. kill, paste v. yank.

 >> because there are no other editors in which there is so much
 >> decoupling between the local equivalents of our core concepts that
 >> they need to be described separately.

True of buffer, I guess, but not of window vs. frame.

 >> There's a parallel with git jargon here...

Indeed.

 > It is very different in one way. An editor is a tool you start
 > with.

That's not what Eric's talking about.  The point he is making, it
seems to me, is that Emacs is not an editor, it is a text editing
environment or toolkit.  Similarly, git is not a VCS, it is an
environment for developing a VCS.  Not to the same extent that today's
Emacs is a development environment for editors, but then Richard had
several years of experience with using a editor language to create the
Emacs Lisp and GNU Emacs that is the direct ancestor of today's Emacs.

Re: Apologia for bzr

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
>  >> Mostly there *aren't* any "standard modern terms",
> 
> You're getting too deep here.  I'm pretty sure what's under discussion
> is cut vs. kill, paste v. yank.

Well, at that level, yes.
 
> That's not what Eric's talking about.  The point he is making, it
> seems to me, is that Emacs is not an editor, it is a text editing
> environment or toolkit.  Similarly, git is not a VCS, it is an
> environment for developing a VCS.

That's exactly correct. Of the level git folks call "plumbing", anyway
- it's almost pure mechanism, no policy. What they call "porcelain" is
a layer on top of that which provides policy and UI.

The analogy between the C core and Emacs Lisp is not perfect, but
neither is it strained or silly. Emacs jargon is complex in the
same way git jargon is because both bottom layers provide a richness
and degree of orthogonality that mone of the competition quite matches.

An important difference is that git porcelain is rather a shambles
compared to Emacs Lisp - usable, but ugly and sharp-edged.  Eli's
complaints are not without justice.

Alas for git's competition, the power of the plumbing combined with
the social momentum of the project as a whole has more than
compensated for the porcelain's deficiencies.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > An important difference is that git porcelain is rather a shambles
 > compared to Emacs Lisp - usable, but ugly and sharp-edged.

Yeah, but in computer time Elisp is to git as David is to Jesus: the
great^24-grandfather.  That's a bit of an unfair comparison.  When
Emacs was git's age, its extension language was TECO and when you
typed C-g in a minibuffer it laughed at you and refused to quit!

Re: Apologia for bzr

[Lennart Borgman]

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

On Sun, Jan 5, 2014 at 11:03 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> Lennart Borgman writes:
>  > On Sat, Jan 4, 2014 at 9:28 AM, Eric S. Raymond <esr@thyrsus.com>
> wrote:
>   > It is very different in one way. An editor is a tool you start
>  > with.
>
> That's not what Eric's talking about.  The point he is making, it
> seems to me, is that Emacs is not an editor, it is a text editing
> environment or toolkit.  Similarly, git is not a VCS, it is an
> environment for developing a VCS.  Not to the same extent that today's
> Emacs is a development environment for editors, but then Richard had
> several years of experience with using a editor language to create the
> Emacs Lisp and GNU Emacs that is the direct ancestor of today's Emacs.
>


When you start with Emacs it is just an editor, nothing more.

[-- Attachment #2: Type: text/html, Size: 1789 bytes --]

Re: Apologia for bzr

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Sun, Jan 5, 2014 at 11:03 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
>
>> Lennart Borgman writes:
>>  > On Sat, Jan 4, 2014 at 9:28 AM, Eric S. Raymond <esr@thyrsus.com>
>> wrote:
>>   > It is very different in one way. An editor is a tool you start
>>  > with.
>>
>> That's not what Eric's talking about.  The point he is making, it
>> seems to me, is that Emacs is not an editor, it is a text editing
>> environment or toolkit.  Similarly, git is not a VCS, it is an
>> environment for developing a VCS.  Not to the same extent that today's
>> Emacs is a development environment for editors, but then Richard had
>> several years of experience with using a editor language to create the
>> Emacs Lisp and GNU Emacs that is the direct ancestor of today's Emacs.
>
> When you start with Emacs it is just an editor, nothing more.

You mean, like an arranged marriage just starts with a spouse, nothing
more?

Women start with vi in the hope it will change, men with Emacs in the
hope it will stay the same.  Both are disappointed.

-- 
David Kastrup

Re: Apologia for bzr

[Werner LEMBERG]

> Women start with vi in the hope it will change, men with Emacs in
> the hope it will stay the same.  Both are disappointed.

Hehe!  This made my day.


    Werner

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Mostly there *aren't* any "standard modern terms", because there are
    no other editors in which there is so much decoupling between the 
    local equivalents of our core concepts that they need to be described
    separately.

There are the standard modern terms cut, paste and copy.

In regard to windows, buffers and frames, we could have a mode of
operation which ties each buffer to a one-window frame.  That would
eliminate a lot of complexity.

We could even offer that as the mode of use for beginners, if that
would make it easier for a new generation of hackers to become Emacs
users.  I don't know whether it WOULD have that effect, but if it
would, I think it is a good idea.

Do beginners typically run Emacs under a graphical window system?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Gabriel Beauchamp]

As still quite beginner myself, I used Emacs in a term for a while, but
now mainly with a graphical environment. And I have only one frame
up. And I don't see the point (at least for me) to have more than one
frame. If I may, I think that most people beggining with Emacs don't see
the point of frames either. If they even know of the existences of
thoses.


2014/1/5, Richard Stallman <rms@gnu.org>:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     Mostly there *aren't* any "standard modern terms", because there are
>     no other editors in which there is so much decoupling between the
>     local equivalents of our core concepts that they need to be described
>     separately.
>
> There are the standard modern terms cut, paste and copy.
>
> In regard to windows, buffers and frames, we could have a mode of
> operation which ties each buffer to a one-window frame.  That would
> eliminate a lot of complexity.
>
> We could even offer that as the mode of use for beginners, if that
> would make it easier for a new generation of hackers to become Emacs
> users.  I don't know whether it WOULD have that effect, but if it
> would, I think it is a good idea.
>
> Do beginners typically run Emacs under a graphical window system?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>
>
>

Re: Apologia for bzr

[Yuri Khan]

On Mon, Jan 6, 2014 at 3:35 AM, Gabriel Beauchamp
<beauchampgabriel@gmail.com> wrote:
> As still quite beginner myself, I used Emacs in a term for a while, but
> now mainly with a graphical environment. And I have only one frame
> up. And I don't see the point (at least for me) to have more than one
> frame.

One starts wanting a second frame as soon as one gets a second monitor.

Re: Apologia for bzr

[Lennart Borgman]

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

On Sun, Jan 5, 2014 at 9:20 PM, Richard Stallman <rms@gnu.org> wrote:

> There are the standard modern terms cut, paste and copy.
>
> It is also about the key-bindings. cua-mode should be a first class
citizen in Emacs. As it is now enabling cua-mode is possible, but the
manuals does not fit entirely when you do. And that is of course troubles
for new users.


> In regard to windows, buffers and frames, we could have a mode of
> operation which ties each buffer to a one-window frame.  That would
> eliminate a lot of complexity.
>

Buffer is a new concept and it is fine. But "frames" and "windows" in Emacs
is of course confusing for beginners. More standard terms would be good for
them, I guess.


> We could even offer that as the mode of use for beginners, if that
> would make it easier for a new generation of hackers to become Emacs
> users.  I don't know whether it WOULD have that effect, but if it
> would, I think it is a good idea.
>
> A mode for beginners would be good, but the exact content of such a mode
is worth considering. As you know I did something like this in the EmacsW32
distribution for MS Windows (which I do not have time to maintain any more,
merging took me too much time since my addiitons took too long to be
accepted into Emacs).


> Do beginners typically run Emacs under a graphical window system?
>

Yes, of course.

[-- Attachment #2: Type: text/html, Size: 2541 bytes --]

Re: Apologia for bzr

[Tom]

Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> 
> A mode for beginners would be good, but the exact content of such a mode is 
worth considering. 

There are various starter kits for beginners already, so there is
existing "research" in this direction. Here's a list of them:

http://ergoemacs.org/misc/list_of_emacs_starter_kits.html

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    But "frames" and "windows" in Emacs
    is of course confusing for beginners. More standard terms would be good for
    them, I guess.

What is the standard term for what we call windows in Emacs?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Lennart Borgman]

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

On Mon, Jan 6, 2014 at 3:00 PM, Richard Stallman <rms@gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     But "frames" and "windows" in Emacs
>     is of course confusing for beginners. More standard terms would be
> good for
>     them, I guess.
>
> What is the standard term for what we call windows in Emacs?
>
>
> Probably this: http://en.wikipedia.org/wiki/Paned_window

[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

Re: Apologia for bzr

[John Yates]

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

On Mon, Jan 6, 2014 at 9:29 AM, Lennart Borgman <lennart.borgman@gmail.com>
 wrote:
>
> Probably this: http://en.wikipedia.org/wiki/Paned_window
>

Pane was exactly the term used by the Apollo Computer Display Manager back
in the early 80s.  A shell window included a line separating unconsumed
editable type-ahead from immutable history.  The two areas were know
respectively as the input pane and the transcript pane.  You can see two
examples in the following image:

http://www.typewritten.org/Media/Images/apollo-dm.png

Window pad0001 displays a privileged shell prompt (#) in the input pane.
 Window pad0002 display a cpscr program executing so no shell prompt ($)
yet.

/john

[-- Attachment #2: Type: text/html, Size: 1378 bytes --]

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Conceivably we could rename "window" to "pane" and "frame" to "window".
I think the two renamings would have to be done in two different releases,
perhaps a year or two apart.

Whether it is worth the trouble, I don't know.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Daniel Colascione]

On 01/06/2014 12:27 PM, Richard Stallman wrote:
> Conceivably we could rename "window" to "pane" and "frame" to "window".
> I think the two renamings would have to be done in two different releases,
> perhaps a year or two apart.

I don't think we could pull off this renaming. At least on the lisp 
level, we would have to maintain compatibility aliases effectively 
forever, doubling the number of lisp symbols dealing with these 
concepts. One does not simply rename a function that's been in constant 
use for 20 years. Sure, you might argue, we could change the labels we 
assign these concepts in the UI and leave lisp alone, but the lisp 
symbols are too closely tied to the UI (with respect to keybindings and 
M-x) to change the two independently.

The best thing we can do is explain in the tutorial and manual the 
correspondence between Emacs and common terms.

Re: Apologia for bzr

[Lennart Borgman]

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

On Mon, Jan 6, 2014 at 9:32 PM, Daniel Colascione <dancol@dancol.org> wrote:

> On 01/06/2014 12:27 PM, Richard Stallman wrote:
>
>> Conceivably we could rename "window" to "pane" and "frame" to "window".
>> I think the two renamings would have to be done in two different releases,
>> perhaps a year or two apart.
>>
>
> I don't think we could pull off this renaming. At least on the lisp level,
> we would have to maintain compatibility aliases effectively forever,
> doubling the number of lisp symbols dealing with these concepts. One does
> not simply rename a function that's been in constant use for 20 years.
> Sure, you might argue, we could change the labels we assign these concepts
> in the UI and leave lisp alone, but the lisp symbols are too closely tied
> to the UI (with respect to keybindings and M-x) to change the two
> independently.
>
> The best thing we can do is explain in the tutorial and manual the
> correspondence between Emacs and common terms.
>

We are talking about the user level. Interactive function names can be
duplicated.

[-- Attachment #2: Type: text/html, Size: 1789 bytes --]

Re: Apologia for bzr

[David Kastrup]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Mon, Jan 6, 2014 at 9:32 PM, Daniel Colascione <dancol@dancol.org> wrote:
>
>> On 01/06/2014 12:27 PM, Richard Stallman wrote:
>>
>>> Conceivably we could rename "window" to "pane" and "frame" to "window".
>>> I think the two renamings would have to be done in two different releases,
>>> perhaps a year or two apart.
>>>
>>
>> I don't think we could pull off this renaming. At least on the lisp level,
>> we would have to maintain compatibility aliases effectively forever,
>> doubling the number of lisp symbols dealing with these concepts. One does
>> not simply rename a function that's been in constant use for 20 years.
>> Sure, you might argue, we could change the labels we assign these concepts
>> in the UI and leave lisp alone, but the lisp symbols are too closely tied
>> to the UI (with respect to keybindings and M-x) to change the two
>> independently.
>>
>> The best thing we can do is explain in the tutorial and manual the
>> correspondence between Emacs and common terms.
>>
>
> We are talking about the user level. Interactive function names can be
> duplicated.

That's a bad idea since a fundamental part of the "interactive" user
interface is completion, so if you are trying to find some
functionality, getting two names in the set of completions that look
like they might do different things because of using different terms,
this will not help the user figuring out what to do.

-- 
David Kastrup

Re: Apologia for bzr

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 12:50 AM, David Kastrup <dak@gnu.org> wrote:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> > On Mon, Jan 6, 2014 at 9:32 PM, Daniel Colascione <dancol@dancol.org>
> wrote:
> >
> >> On 01/06/2014 12:27 PM, Richard Stallman wrote:
> >>
> >>> Conceivably we could rename "window" to "pane" and "frame" to "window".
> >>> I think the two renamings would have to be done in two different
> releases,
> >>> perhaps a year or two apart.
> >>>
> >>
> >> I don't think we could pull off this renaming. At least on the lisp
> level,
> >> we would have to maintain compatibility aliases effectively forever,
> >> doubling the number of lisp symbols dealing with these concepts. One
> does
> >> not simply rename a function that's been in constant use for 20 years.
> >> Sure, you might argue, we could change the labels we assign these
> concepts
> >> in the UI and leave lisp alone, but the lisp symbols are too closely
> tied
> >> to the UI (with respect to keybindings and M-x) to change the two
> >> independently.
> >>
> >> The best thing we can do is explain in the tutorial and manual the
> >> correspondence between Emacs and common terms.
> >>
> >
> > We are talking about the user level. Interactive function names can be
> > duplicated.
>
> That's a bad idea since a fundamental part of the "interactive" user
> interface is completion, so if you are trying to find some
> functionality, getting two names in the set of completions that look
> like they might do different things because of using different terms,
> this will not help the user figuring out what to do.
>
>
There are trade offs, but it is bad logic to say it is a bad idea just
because of that of course.

[-- Attachment #2: Type: text/html, Size: 3186 bytes --]

Re: Apologia for bzr

[Thien-Thi Nguyen]

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

() Lennart Borgman <lennart.borgman@gmail.com>
() Tue, 7 Jan 2014 01:02:53 +0100

   There are trade offs, but it is bad logic to say it is a bad idea
   just because of that of course.

The idea may or may not be bad, but what's that have to do w/ reality?

I think the consequence would be a rapid influx of new users, keen to
experience the Emacs phenomenon, who just as rapidly leave, disgusted,
when all the net.wisdom is largely for the "old (crufty, not the groovy
spectacle i was promised, this sucks, where's my refund)" Emacs.

If they do manage to stick around, OTOH, they will need to join the rest
of us in contemplating, working around, justifying, and (in the end)
condemning the "wanton bifurcation" to their non-Emacs-using and (what's
worse) Emacs-using non-programmer friends.

All archived (thanks NSA), and now net.wisdom is net.dissipation.  Ugh.

On the third hand, who [hn]eeds commentary/code more than 3 solar cycles
past, right?  The sages of Pompeii, they [dl]ie like fools.  Carry on!

-- 
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: Apologia for bzr

[Christophe Poncy]

On 2014-01-06 21:32, Daniel Colascione wrote:
> […]
> 
> The best thing we can do is explain in the tutorial and manual the
> correspondence between Emacs and common terms.

+1

-- 
Support free software! Join FSF:
https://my.fsf.org/associate/support_freedom

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    At least on the lisp 
    level, we would have to maintain compatibility aliases effectively 
    forever, doubling the number of lisp symbols dealing with these 
    concepts.

I don't think it has to be forever.  After a few years,
we could drop the old names.

We could rename `window' to `pane', but not rename `frame'.
That way, there would be no incompatibility, and only one stage
of renaming would be required.

I am still not saying we _should_ do this.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Stefan Monnier]

> Conceivably we could rename "window" to "pane" and "frame" to "window".
> I think the two renamings would have to be done in two different releases,
> perhaps a year or two apart.

Yup, it'd have to be a many-steps process:
- first, rename "window" to "pane"
- then rename "frame" to "window" (so frames would have 3 names:
  screens, frames, and windows; tho admittedly we did finally get rid of
  the "screen" aliases a few years ago).

With a distinction between the Texinfo+docstring level and the Elisp
code level.

At the Lisp level, after renaming selected-window to selected-pane, we'd
have to wait for the selected-window compatibility alias to disappear
before we can rename selected-frame to selected-window.  I'd estimate
that getting rid of the selected-window compatibility alias would take at
least 20 years.

This said, the "what you call a window is called a frame" is not nearly
as problematic as "what we call window is not what you think", so maybe
renaming "window" to "pane" would get us most of the benefit.

So maybe the first step is the only one that really matters, and maybe
my grand children can consider the second step when their time comes.

I'm not sure how much change that represents, but if someone wants to
take a stab at it... I'd be interested to see what it looks like.


        Stefan

Re: Apologia for bzr

[Lars Magne Ingebrigtsen]

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

> This said, the "what you call a window is called a frame" is not nearly
> as problematic as "what we call window is not what you think", so maybe
> renaming "window" to "pane" would get us most of the benefit.

I think you're right there.  If we just get rid of the word "window", I
think that'll fix most confusions.  "Pane" and "frame" are more
"technical" terms, and people aren't as apt to make assumptions about
what they mean.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Apologia for bzr

[Jose E. Marchesi]

    
    > This said, the "what you call a window is called a frame" is not nearly
    > as problematic as "what we call window is not what you think", so maybe
    > renaming "window" to "pane" would get us most of the benefit.
    
    I think you're right there.  If we just get rid of the word
    "window", I think that'll fix most confusions.  "Pane" and "frame"
    are more "technical" terms, and people aren't as apt to make
    assumptions about what they mean.

Aren't we underestimating users's natural ability to abstract terms and
concepts?  For the average person the "confusion" regarding windows will
least for no more than two minutes, if ever, given that both the
tutorial and the manual explain what a window is...

Re: Apologia for bzr

[Per Starbäck]

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

>
>     > This said, the "what you call a window is called a frame" is not
> nearly
>     > as problematic as "what we call window is not what you think", so
> maybe
>     > renaming "window" to "pane" would get us most of the benefit.
>
>     I think you're right there.  If we just get rid of the word
>     "window", I think that'll fix most confusions.  "Pane" and "frame"
>     are more "technical" terms, and people aren't as apt to make
>     assumptions about what they mean.
>
>
+1 to switching from "window", and leave it for a later time to decide when
we're ready to take the next step. That will certainly be a long time from
now, but the long run is what counts the most. And also there is a
significant gain already from step 1.

Aren't we underestimating users's natural ability to abstract terms and
> concepts?  For the average person the "confusion" regarding windows will
> least for no more than two minutes, if ever, given that both the
> tutorial and the manual explain what a window is...
>
>
Users *can* cope, but they have reason to choose not to do that. This is
one of several things where beginning users can get the impression that
Emacs is not for them because it's weird.  If they in just the first half
hour of using Emacs meet several such things they may conclude that working
with Emacs will continue to be like this; now and then it will turn out
that it doesn't work as "expected" and that there are new names for
everything, etc. Why not use That Other Editor that some other people
suggested instead?

[-- Attachment #2: Type: text/html, Size: 2157 bytes --]

Re: Apologia for bzr

[Christophe Poncy]

> Conceivably we could rename "window" to "pane" and "frame" to "window".
> I think the two renamings would have to be done in two different 
> releases,
> perhaps a year or two apart.
> 

I think that "window" is the correct term, it's just that emacs can see 
reality with another dimension, we don't have to put windows side by 
side on the desktop…

-- 
Support free software! Join FSF:
https://my.fsf.org/associate/support_freedom

Re: Apologia for bzr

[joakim]

Christophe Poncy <cp@genium.fr> writes:

>> Conceivably we could rename "window" to "pane" and "frame" to "window".
>> I think the two renamings would have to be done in two different
>> releases,
>> perhaps a year or two apart.
>>
>
> I think that "window" is the correct term, it's just that emacs can
> see reality with another dimension, we don't have to put windows side
> by side on the desktop…

I agree. If you see Emacs as a window manager, most terms Emacs uses
makes good sense IMHO.

-- 
Joakim Verona

Re: Apologia for bzr

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

IBM rewrote X Windows and called the new version "Panes".
Thus, users had AIX and Panes on their RTPC machines.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Apologia for bzr

[Christophe Poncy]

On 2014-01-06 15:29, Lennart Borgman wrote:
> […]
> 
> Probably this: http://en.wikipedia.org/wiki/Paned_window

Here is a short article that has one single interwiki, meaning no 
standard term for that.

-- 
Support free software! Join FSF:
https://my.fsf.org/associate/support_freedom?referrer=4574

Re: Apologia for bzr

[Stefan Monnier]

>     But "frames" and "windows" in Emacs is of course confusing for
>     beginners. More standard terms would be good for them, I guess.

> What is the standard term for what we call windows in Emacs?

Probably "pane"?


        Stefan

Re: Apologia for bzr

[Christophe Poncy]

On 2014-01-06 15:00, Richard Stallman wrote:
> […]
> 
> What is the standard term for what we call windows in Emacs?

No standard there:

* windows in tiling window managers
* frames/iframes in HTML
* windows in Conkeror
* panes in some environments

What we call windows in Emacs can't be produced similarly in most 
applications.


-- 
Support free software! Join FSF:
https://my.fsf.org/associate/support_freedom

Re: Apologia for bzr

[Eric S. Raymond]

Richard Stallman <rms@gnu.org>:
> In regard to windows, buffers and frames, we could have a mode of
> operation which ties each buffer to a one-window frame.  That would
> eliminate a lot of complexity.
> 
> We could even offer that as the mode of use for beginners, if that
> would make it easier for a new generation of hackers to become Emacs
> users.  I don't know whether it WOULD have that effect, but if it
> would, I think it is a good idea.

I'm somewhat doubtful this would be well-directed effort.  In my
experience, he complexity that beginners react badly to is not
multi-window/multi-buffer, it's 1,001 spiky keystroke sequences.
 
> Do beginners typically run Emacs under a graphical window system?

Yes.  It's actually pretty rare for even old-school types to run 
emacs in a hard or soft terminal these days; normally it is launched
from a window system.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Florian Weimer]

* Eric S. Raymond:

> Richard Stallman <rms@gnu.org>:
>> We could even offer that as the mode of use for beginners, if that
>> would make it easier for a new generation of hackers to become Emacs
>> users.  I don't know whether it WOULD have that effect, but if it
>> would, I think it is a good idea.
>
> I'm somewhat doubtful this would be well-directed effort.  In my
> experience, he complexity that beginners react badly to is not
> multi-window/multi-buffer, it's 1,001 spiky keystroke sequences.

Probably.  But exposing windows as tabs by default could be both
familiar and a bit helpful.  Relocating the modeline and minibuffer to
the top of the frame might increase familiarity as well.

Re: Apologia for bzr

[chad]

On 05 Jan 2014, at 13:58, Florian Weimer <fw@deneb.enyo.de> wrote:

> Probably.  But exposing windows as tabs by default could be both
> familiar and a bit helpful.  Relocating the modeline and minibuffer to
> the top of the frame might increase familiarity as well.

Windows as tabs by default would almost certainly improve familiarity by default. The problem with moving windows to tabs is that you need to treat ephemeral buffers differently - you don’t want completions or help hidden on another tab. If anyone is willing to cross the Rubicon, the various gui vim clients do a good job with this kind of tabs-and-windows.

On the other hand, I’ve showed emacs to a very large number of new college students over the years, both programmers and non. The keybindings are confusing to many people. People who accidentally split-window are very confused. Nobody was ever confused by the location of the modeline, and it’s normal for common apps like web browsers to have a “Status Bar” down there. 

~Chad

Re: Apologia for bzr

[Lennart Borgman]

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

On Sun, Jan 5, 2014 at 11:13 PM, chad <yandros@gmail.com> wrote:

>
> Windows as tabs by default would almost certainly improve familiarity by
> default.
> The keybindings are confusing to many people. People who accidentally
> split-window are very confused.
>
> Tabs is a very good feature, but it can't replace "split windows". The
latter must be taught to beginners.

[-- Attachment #2: Type: text/html, Size: 962 bytes --]

Re: Apologia for bzr

[chad]

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


On 05 Jan 2014, at 14:25, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> On Sun, Jan 5, 2014 at 11:13 PM, chad <yandros@gmail.com> wrote:
> 
> Windows as tabs by default would almost certainly improve familiarity by default. 
> The keybindings are confusing to many people. People who accidentally split-window are very confused.
> 
> Tabs is a very good feature, but it can't replace "split windows". The latter must be taught to beginners. 

As stated, I disagree (and this is coming from a person who lived inside emacs-as-window-system for most of a year). It might come from seeing dozens (maybe hundreds) of smart people decide that “Quit Emacs” was the best way to accomplish what I would do with "C-x 1”, and that was before tabs.

I think that *help* and *completions* can teach beginners about split windows just fine, and from there they can learn about split-window-{below,right}, winner/windmove, pop-up-windows, frames, and tabs as fits their preferences.

All that’s IMHO, of course.

~Chad

[-- Attachment #2: Type: text/html, Size: 1999 bytes --]

Re: Apologia for bzr

[Lennart Borgman]

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

On Mon, Jan 6, 2014 at 12:01 AM, chad <yandros@gmail.com> wrote:

>
> On 05 Jan 2014, at 14:25, Lennart Borgman <lennart.borgman@gmail.com>
> wrote:
>
> On Sun, Jan 5, 2014 at 11:13 PM, chad <yandros@gmail.com> wrote:
>
>>
>> Windows as tabs by default would almost certainly improve familiarity by
>> default.
>> The keybindings are confusing to many people. People who accidentally
>> split-window are very confused.
>>
>> Tabs is a very good feature, but it can't replace "split windows". The
> latter must be taught to beginners.
>
>
> As stated, I disagree (and this is coming from a person who lived inside
> emacs-as-window-system for most of a year). It might come from seeing
> dozens (maybe hundreds) of smart people decide that “Quit Emacs” was the
> best way to accomplish what I would do with "C-x 1”, and that was before
> tabs.
>
> I think that *help* and *completions* can teach beginners about split
> windows just fine, and from there they can learn about
> split-window-{below,right}, winner/windmove, pop-up-windows, frames, and
> tabs as fits their preferences.
>
> All that’s IMHO, of course.
>


Eh, I do not think we disagree. ;-)
I just misread you. I thought you said split windows should be replaced by
tabs. Sorry.

I think your suggestion is fine.

[-- Attachment #2: Type: text/html, Size: 3021 bytes --]

Re: Apologia for bzr

[Stefan Monnier]

> On the other hand, I’ve showed emacs to a very large number of new college
> students over the years, both programmers and non.  The keybindings are
> confusing to many people. People who accidentally split-window are very
> confused.  Nobody was ever confused by the location of the modeline, and it’s
> normal for common apps like web browsers to have a “Status Bar” down there. 

That corresponds to my experience.  The main sources of trouble, AFAICT are:
- window management:
  - how to get rid of a window (e.g. when *Help* introduced a split).
  - how to get back to a buffer that was somehow buried.
- keybindings like C-a, C-x, C-c, C-v
- naming (things like windows, frames, kill, yank).


        Stefan

Re: Apologia for bzr

[Sivaram Neelakantan]

On Mon, Jan 06 2014,Stefan Monnier wrote:

>> On the other hand, I’ve showed emacs to a very large number of new college
>> students over the years, both programmers and non.  The keybindings are
>> confusing to many people. People who accidentally split-window are very
>> confused.  Nobody was ever confused by the location of the modeline, and it’s
>> normal for common apps like web browsers to have a “Status Bar” down there. 
>
> That corresponds to my experience.  The main sources of trouble, AFAICT are:
> - window management:
>   - how to get rid of a window (e.g. when *Help* introduced a split).
>   - how to get back to a buffer that was somehow buried.
> - keybindings like C-a, C-x, C-c, C-v
> - naming (things like windows, frames, kill, yank).
>

Speaking as an Emacs user,  I don't understand this line of
reasoning.  The same logic above could be applied to vi/vim, any
programming language at all.  I ran into the same issues above and I
got help from this list or from the docs and even rereading the
tutorial.  What's the issue with new users nowadays?  All the
definitions are there in the manual...erm...somewhere but there.

Back in high school in India, I took French as an optional language to
learn.  Flunked badly.  And my teacher had only one thing to say to me

"Stop thinking in your native language when learning another language"

which I think is the only way to gain a reasonable fluency in using
Emacs i.e. learn Emacs concepts/terminology before proceeding.  And
the Tutorial is more than adequate for the purpose.


 sivaram
 -- 

Re: Apologia for bzr

[David Kastrup]

Sivaram Neelakantan <nsivaram.net@gmail.com> writes:

> On Mon, Jan 06 2014,Stefan Monnier wrote:
>
>>> On the other hand, I’ve showed emacs to a very large number of new college
>>> students over the years, both programmers and non.  The keybindings are
>>> confusing to many people. People who accidentally split-window are very
>>> confused.  Nobody was ever confused by the location of the modeline, and it’s
>>> normal for common apps like web browsers to have a “Status Bar” down there. 
>>
>> That corresponds to my experience.  The main sources of trouble, AFAICT are:
>> - window management:
>>   - how to get rid of a window (e.g. when *Help* introduced a split).
>>   - how to get back to a buffer that was somehow buried.
>> - keybindings like C-a, C-x, C-c, C-v
>> - naming (things like windows, frames, kill, yank).
>>
>
> Speaking as an Emacs user,  I don't understand this line of
> reasoning.  The same logic above could be applied to vi/vim, any
> programming language at all.  I ran into the same issues above and I
> got help from this list or from the docs and even rereading the
> tutorial.  What's the issue with new users nowadays?  All the
> definitions are there in the manual...erm...somewhere but there.

Help/Search Documentation/Emacs Terminology.

-- 
David Kastrup

Re: Apologia for bzr

[Stefan Monnier]

> which I think is the only way to gain a reasonable fluency in using
> Emacs i.e. learn Emacs concepts/terminology before proceeding.  And
> the Tutorial is more than adequate for the purpose.

Probably most Emacs users agree.  And those who don't just move on to
greener pastures.


        Stefan

Re: Apologia for bzr

[Christophe Poncy]

On 2014-01-06 15:09, Sivaram Neelakantan wrote:
> […]
> 
> "Stop thinking in your native language when learning another language"
> 
> which I think is the only way to gain a reasonable fluency in using
> Emacs i.e. learn Emacs concepts/terminology before proceeding.  And
> the Tutorial is more than adequate for the purpose.
> 

+1

-- 
Support free software! Join FSF:
https://my.fsf.org/associate/support_freedom?referrer=4574

Re: Apologia for bzr

[James Cloos]

>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:

ESR> Yes.  It's actually pretty rare for even old-school types to run
ESR> emacs in a hard or soft terminal these days; normally it is
ESR> launched from a window system.

Except when using emacs on a remote server.

Emacs in a terminal emulator is often superior to gui-emacs with the X
protocol tunneled over ssh.

I just tried the latter (using lucid; gtk is known to be especially
awful over tcp) and it took (in fact is taking) minutes to get the
initial frame up and responsive.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Apologia for bzr

[Karl Fogel]

James Cloos <cloos@jhcloos.com> writes:
>>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
>ESR> Yes.  It's actually pretty rare for even old-school types to run
>ESR> emacs in a hard or soft terminal these days; normally it is
>ESR> launched from a window system.
>
>Except when using emacs on a remote server.

FWIW, I do this (appx) daily, as do many admins I know.

>Emacs in a terminal emulator is often superior to gui-emacs with the X
>protocol tunneled over ssh.

Ezzactly :-).

Re: Apologia for bzr

[Eric S. Raymond]

James Cloos <cloos@jhcloos.com>:
> >>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
> 
> ESR> Yes.  It's actually pretty rare for even old-school types to run
> ESR> emacs in a hard or soft terminal these days; normally it is
> ESR> launched from a window system.
> 
> Except when using emacs on a remote server.

Agreed.  That's the same exception case I was thinking of.  Happens
to me maybe twice a year.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[David Kastrup]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
>
> ESR> Yes.  It's actually pretty rare for even old-school types to run
> ESR> emacs in a hard or soft terminal these days; normally it is
> ESR> launched from a window system.
>
> Except when using emacs on a remote server.
>
> Emacs in a terminal emulator is often superior to gui-emacs with the X
> protocol tunneled over ssh.

Why would you do that?

It's so much easier and faster to just do

C-x C-f /ssh:user@hostname.netword:myfile.c RET

and you don't even need an Emacs on the other end of the connection.
Similarly for editing things like

C-x C-f /sudo::/etc/fstab RET

-- 
David Kastrup

Re: Apologia for bzr

[Eric Brown]

David Kastrup <dak@gnu.org> writes:

> Why would you do that?
>
> It's so much easier and faster to just do
>
> C-x C-f /ssh:user@hostname.netword:myfile.c RET
>
> and you don't even need an Emacs on the other end of the connection.
> Similarly for editing things like
>
> C-x C-f /sudo::/etc/fstab RET

As an example of where this does not work, I must use Citrix software to
connect the my server.  Unfortunately, I do not have direct ssh access.

Also, does this transfer the file to a local temporary directory?  If
the edited files are large/manifold, this could be a problem.

(Citrix is mandated by my employer, and its unlikely they will be
moved to change. I'm grateful that I can access free software albeit via
this proprietary mechanism.)

Re: Apologia for bzr

[David Kastrup]

Eric Brown <eric.c.brown@mac.com> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Why would you do that?
>>
>> It's so much easier and faster to just do
>>
>> C-x C-f /ssh:user@hostname.netword:myfile.c RET
>>
>> and you don't even need an Emacs on the other end of the connection.
>> Similarly for editing things like
>>
>> C-x C-f /sudo::/etc/fstab RET
>
> As an example of where this does not work, I must use Citrix software to
> connect the my server.  Unfortunately, I do not have direct ssh access.

Tramp can be configured to use a lot of different transfer methods.  As
long as you have any kind of remote shell access...

> Also, does this transfer the file to a local temporary directory?  If
> the edited files are large/manifold, this could be a problem.

If bandwidth is scarce, a transparent X session will be awful too.

-- 
David Kastrup

Re: Apologia for bzr

[Yuri Khan]

On Mon, Jan 6, 2014 at 7:45 AM, David Kastrup <dak@gnu.org> wrote:
> James Cloos <cloos@jhcloos.com> writes:
>>
>> Emacs in a terminal emulator is often superior to gui-emacs with the X
>> protocol tunneled over ssh.
>
> Why would you do that?
>
> It's so much easier and faster to just [use TRAMP]

Because workflow.

You ssh into a remote server, perhaps with a need to investigate a
problem. You see the process list; a critical service process is dead.
You read some logs (probably with tail and/or less); they are not
detailed enough. You try to restart the service, but it still dies
soon and logs are still not detailed enough for you to understand what
is happening.

At this point, the natural next thing is to say “editor
/etc/foo/bar.conf” to raise the logging level a bit. But this fires up
the default editor at the remote server, not a TRAMP editing session
on your local Emacs.

Or you have to switch to a different application (from terminal
emulator to Emacs), and then press C-x C-f, and then type out that
whole remote path, and possibly enter your password again.


Maybe you have a solution to this issue? What incantation on the
remote server do I need to invoke in order to edit a remote file,
specified by its remote path (absolute or relative to the remote
current directory), in a local Emacs via TRAMP? What non-default setup
will be needed on the remote and/or local? (E.g. run Emacs server on
local/tcp and tunnel the server port to the remote, then use remote
emacsclient? Will it be secure against concurrent other users of the
same remote?)

Re: Apologia for bzr

[Michael Albinus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> Because workflow.
>
> You ssh into a remote server, perhaps with a need to investigate a
> problem. You see the process list; a critical service process is dead.
> You read some logs (probably with tail and/or less); they are not
> detailed enough. You try to restart the service, but it still dies
> soon and logs are still not detailed enough for you to understand what
> is happening.
>
> At this point, the natural next thing is to say “editor
> /etc/foo/bar.conf” to raise the logging level a bit. But this fires up
> the default editor at the remote server, not a TRAMP editing session
> on your local Emacs.
>
> Or you have to switch to a different application (from terminal
> emulator to Emacs), and then press C-x C-f, and then type out that
> whole remote path, and possibly enter your password again.
>
>
> Maybe you have a solution to this issue? What incantation on the
> remote server do I need to invoke in order to edit a remote file,
> specified by its remote path (absolute or relative to the remote
> current directory), in a local Emacs via TRAMP? What non-default setup
> will be needed on the remote and/or local? (E.g. run Emacs server on
> local/tcp and tunnel the server port to the remote, then use remote
> emacsclient? Will it be secure against concurrent other users of the
> same remote?)

Using Tramp in this workflow makes sense if your primary investigations
are already performed inside Emacs, using `M-x shell' or `M-x eshell'.

Reading a log tail-wise is possible with `M-x auto-revert-tail-mode'.

That's what I do daily, but maybe I'm biased in favor of Tramp.

Best regards, Michael.

Re: Apologia for bzr

[chad]

On 05 Jan 2014, at 20:27, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Mon, Jan 6, 2014 at 7:45 AM, David Kastrup <dak@gnu.org> wrote:
>> James Cloos <cloos@jhcloos.com> writes:
>>> 
>>> Emacs in a terminal emulator is often superior to gui-emacs with the X
>>> protocol tunneled over ssh.
>> 
>> Why would you do that?
>> 
>> It's so much easier and faster to just [use TRAMP]
> 
> Because workflow.

Thats what leads emacs users to Tramp, also: emacs users tend to
do everything in emacs (until gnus/etc freeze emacs while updating,
at which point they tend to:

	Get annoyed.
	Think about adding threading/coroutines/etc to elisp.
	Start a second emacs.
	Get something to drink.

Its quite common to choose more than one at a time, of course.

More seriously, tramp users would probably be sshing in from within
emacs, and even if they didnt for some reason, theyre first instinct
to edit is switch to emacs and, not start an editor. Ive seen people
make emacsclient work in that situation, but I dunno what the current
state of the art is.

At the end of the day, though, Ive frequently been glad that emacs
works well in a terminal, and a limited remote link is the major
reason. I doubt its going away any time soon.

~Chad

Re: Apologia for bzr

[James Cloos]

>>>>> "DK" == David Kastrup <dak@gnu.org> writes:

JC>> Emacs in a terminal emulator is often superior to gui-emacs with the X
JC>> protocol tunneled over ssh.

DK> Why would you do that?

DK> It's so much easier and faster to just do

DK> C-x C-f /ssh:user@hostname.netword:myfile.c RET

No it is not faster.

If I need to edit something, I'll alread have an ssh session open to
that box.  >emacs foo< is a hell of a lot faster than switching to a
different (window manager) workspace and typing all of that....

And, often, the editing I'm doing is an automated call to $EDITOR.
So it has to run local to the remote box anyway.

Further, testing shows that although tramp logs in to the remote box, it
never gets past waiting for prompts.  So it isn't just slower; it doesn't
work at all.

(Not to mention the secondary gnus instance I run on one of my servers.)

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Apologia for bzr

[Eric Brown]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Richard Stallman <rms@gnu.org>:

>> We could even offer that as the mode of use for beginners, if that
>> would make it easier for a new generation of hackers to become Emacs
>> users.  I don't know whether it WOULD have that effect, but if it
>> would, I think it is a good idea.

>> Do beginners typically run Emacs under a graphical window system?
>
> Yes.  It's actually pretty rare for even old-school types to run 
> emacs in a hard or soft terminal these days; normally it is launched
> from a window system.

The "beginners" and "experts" that I work with are expected (and
desire!) to be able to work with Emacs being run through GNU screen, in
a old-school terminal window.

This allows us to easily reconnect to Emacs sessions that serve as the
REPL for long-running code written in, e.g. GNU R.

Unfortunately, we haven't had much luck reconnecting to X11 sessions
(hence GUI Emacs).  It turns out, we really don't need it for our
particular purposes.

Also, one of Eli's recent patches makes drop-down menus in terminal
windows; this removes one of terminal Emacs' "less-pretty" features and
increases accessibility through familiarity.

Re: Apologia for bzr

[Rogerio Senna]

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

On Sun, Jan 5, 2014 at 6:56 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Richard Stallman <rms@gnu.org>:
> > In regard to windows, buffers and frames, we could have a mode of
> > operation which ties each buffer to a one-window frame.  That would
> > eliminate a lot of complexity.
> >
> > We could even offer that as the mode of use for beginners, if that
> > would make it easier for a new generation of hackers to become Emacs
> > users.  I don't know whether it WOULD have that effect, but if it
> > would, I think it is a good idea.
>
> I'm somewhat doubtful this would be well-directed effort.  In my
> experience, he complexity that beginners react badly to is not
> multi-window/multi-buffer, it's 1,001 spiky keystroke sequences.
>

I couldn't help but notice that this (having each buffer tied to a single
frame) really sounds like One On One
Emacs<http://www.emacswiki.org/emacs/OneOnOneEmacs>
.

[-- Attachment #2: Type: text/html, Size: 1389 bytes --]

RE: Apologia for bzr

[Drew Adams]

>>> In regard to windows, buffers and frames, we could have a mode of
>>> operation which ties each buffer to a one-window frame.  That would
>>> eliminate a lot of complexity.
>>>
>>> We could even offer that as the mode of use for beginners, if that
>>> would make it easier for a new generation of hackers to become Emacs
>>> users.  I don't know whether it WOULD have that effect, but if it
>>> would, I think it is a good idea.
>>
>> I'm somewhat doubtful this would be well-directed effort.  In my
>> experience, he complexity that beginners react badly to is not
>> multi-window/multi-buffer, it's 1,001 spiky keystroke sequences.
>
> I couldn't help but notice that this (having each buffer tied to a
> single frame) really sounds like One On One Emacs.

;-)

But One On One Emacs does *not* tie a buffer to a frame.  Only
*Help*, *Completions*, and special-display buffers have dedicated
windows (by default).

You can split windows, visit a different buffer in the same frame,
or do anything else that you might normally do in Emacs.  The main
difference is that when you display a buffer it typically pops up
in a separate frame.

Re: Apologia for bzr

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

> They are impenetrable.  The very first words will get you in a "WTF?"
> mode.

All the terminology that's referred to in the git command man pages is
defined in one central place, the gitglossary(7) man page.  But in fact,
basically every git command man page should list that under SEE ALSO but
doesn't.

> Just try to read the first sentences of any random man page through a
> newbie's eyes.  No term is ever explained before used -- do these guys
> even understand what it means to _explain_ things?

With respect to newby friendliness: probably bzr is easier to grasp if
you haven't used a (d)VCS before, but in the presence of extremely
popular sites such as gitorious and github, most potential (Emacs)
contributors have gotten in touch with git anyway.  That's the case for
me, and I sometimes mess up my bzr checkout just because I naively
transfer my usual git habits and workflow to bzr.  Of course, I
shouldn't do that, but that's probably a trap many people coming from
git to bzr will fall in.

Another strong point of git is getting support.  When I started with it,
I sometimes messed up my checkouts just as I'm messing up things with
bzr nowadays.  But just by explaining what I've done on
#git@irc.freenode.net (right now there are ~1000 users in there so
there's almost certainly someone with very deep git knowledge) I was
able to recover within minutes.  With bzr, I usually ask here on
emacs-devel because the bzr support channel is quite unresponsive
nowadays, and then you, Eli, will give me the answers I'm looking for
(thanks again!).  But nevertheless, with git you can really get 24/7
handholding if you want to.

Bye,
Tassilo

Re: Apologia for bzr

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 10:44:17 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > They are impenetrable.  The very first words will get you in a "WTF?"
> > mode.
> 
> All the terminology that's referred to in the git command man pages is
> defined in one central place, the gitglossary(7) man page.

First, there are no references to glossary in these places, and, as
you know well, references in man pages are a PITA to use (unlike in
Info).

More importantly, the glossary, at least git's glossary, is not going
to help here.  Let's take this example I showed earlier:

  --reuse-message=<commit> 
    Take an existing commit object, and reuse the log message and the
    authorship information (including the timestamp) when creating the
    commit.

Clearly, what I need to know here, and is never explained, is how do I
_reference_ a commit object.  Now, here's what the glossary tells me:

  commit object 
       An object which contains the information about a particular
       revision, such as parents, committer, author, date and the tree
       object which corresponds to the top directory of the stored
       revision.

I hope you will agree with me that after reading this, I'm none the
wiser.  (There are a few hyperlinks in the text I show above, but none
of them helps, either.)  It actually tells me things that I could
easily guessed myself, but never even hints at what I'm looking for.
Reminds me of Microsoft documentation: to open a file click File->Open.

> But in fact, basically every git command man page should list that
> under SEE ALSO but doesn't.

That's impractical: it would make the See Also section be of infinite
length.  Instead, the man page should either use a less formal style,
or give examples (e.g., in parentheses) showing how the formal
abstract terminology is related to practical issues.

IOW, the authors should recognize that when I'm reading a man page, I
usually look for answers to very practical questions, I'm not very
interested in abstract relations between abstract opaque objects and
concepts.

Re: Apologia for bzr

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

> First, there are no references to glossary in these places, and, as
> you know well, references in man pages are a PITA to use (unlike in
> Info).

Few people probably know that Git can be compiled with Info
documentation.  The manual that gets built contains all the man-page
reference material in addition to the Git User's Manual, which is more
like a tutotial than a reference.

Re: Apologia for bzr

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> Cc: Tassilo Horn <tsdh@gnu.org>,  esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 05:56:43 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > First, there are no references to glossary in these places, and, as
> > you know well, references in man pages are a PITA to use (unlike in
> > Info).
> 
> Few people probably know that Git can be compiled with Info
> documentation.

Hey, I don't compile mine, I just use whatever the msys-git
installation comes with, and what's installed on the Unix systems I
use.  None of them has anything pertinent in /usr/share/info/.

Re: Apologia for bzr

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

> Hey, I don't compile mine, I just use whatever the msys-git
> installation comes with, and what's installed on the Unix systems I
> use.  None of them has anything pertinent in /usr/share/info/.

I really didn't either.  Just built and installed the info docs once.
If you don't want to do that, you can just google "Git User's Manual".
It's actually pretty decent.

Re: Apologia for bzr

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> Cc: esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org,  tsdh@gnu.org
> Date: Fri, 03 Jan 2014 06:49:15 -0500
> 
> If you don't want to do that, you can just google "Git User's Manual".

Thanks, will do.

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Fri, 03 Jan 2014 15:54:38 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: esr@thyrsus.com, kfogel@red-bean.com, tsdh@gnu.org, emacs-devel@gnu.org
> 
> > From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> > Cc: esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org,  tsdh@gnu.org
> > Date: Fri, 03 Jan 2014 06:49:15 -0500
> > 
> > If you don't want to do that, you can just google "Git User's Manual".
> 
> Thanks, will do.

I ended up building the git Info docs myself.  It was an uphill
battle, but I won.

Re: Apologia for bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Hey, I don't compile mine, I just use whatever the msys-git
> installation comes with, and what's installed on the Unix systems I
> use.  None of them has anything pertinent in /usr/share/info/.

MSYSGit `git help foo' launches a web browser showing the man page for
command `foo' with working hyperlinks. I tried a few commands and at the
bottom there is a link to git(1). From there you can access a tutorial,
a quick intro, a full manual and the glossary.

Re: Apologia for bzr

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 16:06:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Hey, I don't compile mine, I just use whatever the msys-git
> > installation comes with, and what's installed on the Unix systems I
> > use.  None of them has anything pertinent in /usr/share/info/.
> 
> MSYSGit `git help foo' launches a web browser showing the man page for
> command `foo' with working hyperlinks. I tried a few commands and at the
> bottom there is a link to git(1). From there you can access a tutorial,
> a quick intro, a full manual and the glossary.

Yes, I use all that.  Useless, see my previous posts.

Re: Apologia for bzr

[Leo Liu]

On 2014-01-03 18:26 +0800, Eli Zaretskii wrote:
> More importantly, the glossary, at least git's glossary, is not going
> to help here.  Let's take this example I showed earlier

GIT's manual pages, good or bad, is not the issue. The issue is
programmers using git have outnumbered bzr and hg combined. Most people
are already familiar with git's jargon or whatnot.

A few years ago I counted the number of users on #git, #hg and #bzr @
freenode. hg users were a quarter of git's. bzr users under two digits.
If you ask a question on #bzr, you can get a reply in half a day at
best.

I think getting new blood into emacs devel is critical or we might find
ourselves in the same situation as bzr a few years later.

Leo

Re: Apologia for bzr

[Eli Zaretskii]

> From:  Leo Liu <sdl.web@gmail.com>
> Cc: Tassilo Horn <tsdh@gnu.org>,  esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 21:49:05 +0800
> 
> On 2014-01-03 18:26 +0800, Eli Zaretskii wrote:
> > More importantly, the glossary, at least git's glossary, is not going
> > to help here.  Let's take this example I showed earlier
> 
> GIT's manual pages, good or bad, is not the issue.

They are the issue in this thread, because it started when I was asked
about my reasons for hating it.  Perhaps you meant to post in another
thread (of which there are too many)?

> I think getting new blood into emacs devel is critical or we might find
> ourselves in the same situation as bzr a few years later.

I agree about the need, but have my doubts about the results.  We've
heard similar arguments for switching from CVS, too.  I hope I will be
proven wrong.

Re: Apologia for bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think getting new blood into emacs devel is critical or we might find
>> ourselves in the same situation as bzr a few years later.
>
> I agree about the need, but have my doubts about the results.  We've
> heard similar arguments for switching from CVS, too.  I hope I will be
> proven wrong.

Switching from CVS to a dVCS was a good move (I think you agreed with
this on previous posts on this ml.) But, if you wished to attract users,
choosing a tool that requires from almost everybody to learn it for the
sole purpose of contributing to Emacs was most unfortunate. Emacs would
be better off with CVS on this regard.

Re: Apologia for bzr

[Eric S. Raymond]

Óscar Fuentes <ofv@wanadoo.es>:
> Switching from CVS to a dVCS was a good move (I think you agreed with
> this on previous posts on this ml.) But, if you wished to attract users,
> choosing a tool that requires from almost everybody to learn it for the
> sole purpose of contributing to Emacs was most unfortunate. Emacs would
> be better off with CVS on this regard.

I wouldn't go *that* far. In 2013/2014, CVS is a bad joke. People laughed
and pointed.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Stefan Monnier]

> sole purpose of contributing to Emacs was most unfortunate.  Emacs would
> be better off with CVS on this regard.

Nowadays, CVS is only know by "old farts" and is otherwise a weird out-lier.


        Stefan

Re: Apologia for bzr

[Stefan Monnier]

>> I think getting new blood into emacs devel is critical or we might find
>> ourselves in the same situation as bzr a few years later.
> I agree about the need, but have my doubts about the results.  We've
> heard similar arguments for switching from CVS, too.  I hope I will be
> proven wrong.

Using Git won't magically give us any new blood.  But using Bzr is
a hindrance.  A few years ago, users seemed happy to use Hg for one
project, Git for another, DaRCS for yet a third, etc....

Nowadays most users complain when they have to learn another tool.


        Stefan

Re: Apologia for bzr

[David Kastrup]

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

> Using Git won't magically give us any new blood.  But using Bzr is
> a hindrance.  A few years ago, users seemed happy to use Hg for one
> project, Git for another, DaRCS for yet a third, etc....
>
> Nowadays most users complain when they have to learn another tool.

Nowadays most users complain when they have to learn.

Nowadays most users complain.

But that's, again, a side consideration.

I am currently involved with LilyPond, a music typesetter and working as
a fulltime programmer on it.  So I am doing plenty of additions.

Like one sees with many significant contributors and/or project leaders,
I spend so much working _on_ LilyPond that I have factually ceased
working _with_ LilyPond.  So quite a few significant usability
improvements happen when I

a) on a rare occasion actually have to transcribe some music piece and
get appalled at how weird something is
b) try explaining on a mailing list how to do some programming or
transcribing task with LilyPond and get appalled at how weird something
is.
c) try writing documentation for some problem and get appalled at how
weird...

You get the point.  Often the weirdness is decades old and people just
got used to it.

Now in this discussion here, for better or worse, there is the somewhat
handwavingly made contention "everybody uses Git nowadays".  Now if
Emacs is supposed to be useful to people, that means it should support
Git well.

If we stipulate that the main task several powerful Emacs contributors
are using Emacs for is, well, working on Emacs, then their focus to get
weird things or things not matching the tool well under control will be
on the version control system they are using in connection with working
on Emacs.

So if we don't have a particular axe to grind for a particular version
control system, it makes sense moving Emacs to what is used most often,
just so that the friction between Emacs' and PVCS' keybindings,
commands, documentation, workflow, concepts will be most obvious when
working with the most prevalent version control system.

When Eli says "working with Git under Windows is a pain", then it may be
nice to have as the ultimate goal the addition "unless you are working
with it from within Emacs".

Emacs is really great for working on Texinfo, Lisp, and C files.  And
part of the reason it has strong points there is that these are the
languages involved with working on Emacs itself.

-- 
David Kastrup

Re: Apologia for bzr

[Dmitry Gutov]

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

> Using Git won't magically give us any new blood.  But using Bzr is
> a hindrance.  A few years ago, users seemed happy to use Hg for one
> project, Git for another, DaRCS for yet a third, etc....
>
> Nowadays most users complain when they have to learn another tool.

It could mean the users are getting more spoiled, or it could indicate
increasing mainstream acceptance of Emacs, when it attracts more users
who don't really like to learn new tools.

Re: Apologia for bzr

[Eric S. Raymond]

Dmitry Gutov <dgutov@yandex.ru>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Using Git won't magically give us any new blood.  But using Bzr is
> > a hindrance.  A few years ago, users seemed happy to use Hg for one
> > project, Git for another, DaRCS for yet a third, etc....
> >
> > Nowadays most users complain when they have to learn another tool.
> 
> It could mean the users are getting more spoiled, or it could indicate
> increasing mainstream acceptance of Emacs, when it attracts more users
> who don't really like to learn new tools.

It could mean any of those things. 

What I think it means is that git has achieved ubiquity and become
part of most peoples' notion of a baseline toolkit, in the same way
that C compilers did after about 1985.

I don't think it has much of anything to do with the acceptance level of Emacs.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Stefan Monnier]

>> Using Git won't magically give us any new blood.  But using Bzr is
>> a hindrance.  A few years ago, users seemed happy to use Hg for one
>> project, Git for another, DaRCS for yet a third, etc....
>> Nowadays most users complain when they have to learn another tool.
> It could mean the users are getting more spoiled,

Kind of, yes.  More specifically, people had no choice but to regularly
learn a new VCS tool every once in a while, whereas nowadays it's rare.
So people's understanding of what is a VCS used to be less
custom-tailored to a particular VCS than it is nowadays.

Kind of like when you have to use a different text editor in each one of
your web-browser, MUA, word processor, IDE, instant-messaging, ...
you end up only using the common-denominator bindings and you don't mind
having to use yet-another-editor.  But when you do all your text editing
in (say) Emacs, having to use another editor for your web-browsing needs
is really irksome.


        Stefan

Re: Apologia for bzr

[Josh]

On Fri, Jan 3, 2014 at 11:49 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> I think getting new blood into emacs devel is critical or we might find
>>> ourselves in the same situation as bzr a few years later.
>> I agree about the need, but have my doubts about the results.  We've
>> heard similar arguments for switching from CVS, too.  I hope I will be
>> proven wrong.
>
> Using Git won't magically give us any new blood.  But using Bzr is
> a hindrance.

Indeed, that removing hindrances to becoming a contributor should
result in new contributors is not magic, but common sense.

> A few years ago, users seemed happy to use Hg for one
> project, Git for another, DaRCS for yet a third, etc....

I suspect that in those days, as now, users decided whether or
not to invest the time to learn a new tool based mainly on their
assessment of the likely payoff of the investment.  Given Git's
present dominance[0] and the attendant benefits from network
effects, it's no surprise that a bias has emerged among users
that did not exist a few short years ago.

> Nowadays most users complain when they have to learn another tool.

Tsk, can you believe these kids today?! ;)

[0] http://qa.debian.org/popcon-graph.php?packages=cvs+git+bzr+mercurial+darcs+subversion+rcs++&show_vote=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2008-01-01&to_date=2014-01-30&hlght_date=&date_fmt=%25Y&beenhere=1

Re: Apologia for bzr

[Eric S. Raymond]

Leo Liu <sdl.web@gmail.com>:
> I think getting new blood into emacs devel is critical or we might find
> ourselves in the same situation as bzr a few years later.

+1

This is my fear as well.  Switching to git is not sufficient to avert that 
outcome, but I think it is necessary.

There are other things we need to do to let sunlight and fresh air into the 
room.  The people who think of Emacs as a relic of bygone decades inhabited
by graying neckbeards are not, alas, entirely wrong.  And I say that as
arguably one of the neckbeards myself...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Apologia for bzr

[Karl Fogel]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>There are other things we need to do to let sunlight and fresh air into the 
>room.  The people who think of Emacs as a relic of bygone decades inhabited
>by graying neckbeards are not, alas, entirely wrong.  And I say that as
>arguably one of the neckbeards myself...

Right now, two of the biggest sources of hacking energy in the
Emacsosphere are in git repositories separate from Emacs' own bzr
repository: Org Mode and Gnus.  Our switching to git will help reduce at
least the degree of separation.

Whether those projects eventually host their "socially agreed on"
primary development branches in Emacs' repository is another question; I
don't know those dev communities well enough to say, despite being a
heavy user of both packages :-).  But the mere fact that I instinctively
consider them to be somewhat separate developer communities from Emacs
itself may be partly an artifact of our having been on bzr for so long.

-K

Re: Apologia for bzr

[Ted Zlatanov]

On Fri, 03 Jan 2014 11:56:51 -0600 Karl Fogel <kfogel@red-bean.com> wrote: 

KF> "Eric S. Raymond" <esr@thyrsus.com> writes:
>> There are other things we need to do to let sunlight and fresh air into the 
>> room.  The people who think of Emacs as a relic of bygone decades inhabited
>> by graying neckbeards are not, alas, entirely wrong.  And I say that as
>> arguably one of the neckbeards myself...

KF> Right now, two of the biggest sources of hacking energy in the
KF> Emacsosphere are in git repositories separate from Emacs' own bzr
KF> repository: Org Mode and Gnus.  Our switching to git will help reduce at
KF> least the degree of separation.

Have you seen the amount of activity on GNU ELPA, MELPA, el-get, and
others?  The amount and variety of packages are amazing.

KF> Whether those projects eventually host their "socially agreed on"
KF> primary development branches in Emacs' repository is another question; I
KF> don't know those dev communities well enough to say, despite being a
KF> heavy user of both packages :-).  But the mere fact that I instinctively
KF> consider them to be somewhat separate developer communities from Emacs
KF> itself may be partly an artifact of our having been on bzr for so long.

Heh heh.  As someone on both sides (Gnus and Emacs) I have to say
contributing to Gnus through Git has been much less stressful for me.

Ted

Re: Apologia for bzr

[Karl Fogel]

Ted Zlatanov <tzz@lifelogs.com> writes:
>KF> Right now, two of the biggest sources of hacking energy in the
>KF> Emacsosphere are in git repositories separate from Emacs' own bzr
>KF> repository: Org Mode and Gnus.  Our switching to git will help reduce at
>KF> least the degree of separation.
>
>Have you seen the amount of activity on GNU ELPA, MELPA, el-get, and
>others?  The amount and variety of packages are amazing.

True; I didn't mean to slight other packages.

Emacs' extensible, modular nature probably means that activity on the
core development list and repository is not an accurate measure of how
the project is doing as a whole anyway.

David Engster wrote:
>In what way? They are still different repositories; just because they
>are both using git does not magically make things easier.
>
>Unless of course you propose to include Gnus and Org as a submodule,
>which would make sense, but is difficult to pull off.

I guess I really meant "If they switch to having a common branch history
with core Emacs, then merging and change porting gets a lot easier,
whether or not they use the same social master repository" (but that's
not what I said, so your question was quite reasonable).

-K

Re: Apologia for bzr

[Stefan Monnier]

> I guess I really meant "If they switch to having a common branch history
> with core Emacs, then merging and change porting gets a lot easier,

As you know, there is no VCS tool out there that can actually handle
such a thing.  Two-way syncs between different branches is still an
open problem.


        Stefan

Re: Apologia for bzr

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I guess I really meant "If they switch to having a common branch history
>> with core Emacs, then merging and change porting gets a lot easier,
>
>As you know, there is no VCS tool out there that can actually handle
>such a thing.  Two-way syncs between different branches is still an
>open problem.

?  No, I meant what I said, but it's possible I said it too compactly.
(If you want, I can explain in more detail off-list, but I won't go into
it more here as it's tangential to our immediate concerns -- i.e., feel
free to drop it, as I think it's an academic point given the accumulated
history of those projects on their own branches :-) ).

­K

Re: Apologia for bzr

[David Engster]

Stefan Monnier writes:
>> I guess I really meant "If they switch to having a common branch history
>> with core Emacs, then merging and change porting gets a lot easier,
>
> As you know, there is no VCS tool out there that can actually handle
> such a thing.  Two-way syncs between different branches is still an
> open problem.

The question is whether you would consider adding projects as submodules
to the Emacs repository. I think this would make sense for CEDET; we
already have a branch upstream which mirrors the lisp/cedet directory in
Emacs. This would of course imply that we move our repository from
Sourceforge to Savannah, and sync our user lists so that people can
push.

It'd be premature to discuss details now, of course, but I know that not
everyone is fond of submodules, and I'd just like to know if you're one
of those. :-)

-David

Re: Apologia for bzr

[Stefan Monnier]

> It'd be premature to discuss details now, of course, but I know that not
> everyone is fond of submodules, and I'd just like to know if you're one
> of those. :-)

I'm not in love with them, but I would not rule them out.
And I do feel like it would be good to avoid the two-way sync, so
something like a submodule is indeed an attractive option.


        Stefan

Re: Apologia for bzr

[chad]

On 03 Jan 2014, at 10:04, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Have you seen the amount of activity on GNU ELPA, MELPA, el-get, and
> others?  The amount and variety of packages are amazing.

Related note: anyone whos interested in this (primarily social)
topic, and doesnt mind using modern web sites, should consider
following emacs.reddit.com. Maybe its just me (kids these days,
etc, etc), but I was quite heartened to see so much activity around
emacs.

~Chad

Re: Apologia for bzr

[David Engster]

Karl Fogel writes:
> Right now, two of the biggest sources of hacking energy in the
> Emacsosphere are in git repositories separate from Emacs' own bzr
> repository: Org Mode and Gnus.  Our switching to git will help reduce at
> least the degree of separation.

In what way? They are still different repositories; just because they
are both using git does not magically make things easier.

Unless of course you propose to include Gnus and Org as a submodule,
which would make sense, but is difficult to pull off.

-David

Re: Apologia for bzr

[Bastien]

Karl Fogel <kfogel@red-bean.com> writes:

> "Eric S. Raymond" <esr@thyrsus.com> writes:
>>There are other things we need to do to let sunlight and fresh air into the 
>>room.  The people who think of Emacs as a relic of bygone decades inhabited
>>by graying neckbeards are not, alas, entirely wrong.  And I say that as
>>arguably one of the neckbeards myself...
>
> Right now, two of the biggest sources of hacking energy in the
> Emacsosphere are in git repositories separate from Emacs' own bzr
> repository: Org Mode and Gnus.  Our switching to git will help reduce at
> least the degree of separation.

Well, I don't really know where Emacs hacking energy is really spent
on, but I discover new Emacs stuff every day so my impression is that
the ecosystem at large is quite productive.
 
> Whether those projects eventually host their "socially agreed on"
> primary development branches in Emacs' repository is another question; I
> don't know those dev communities well enough to say, despite being a
> heavy user of both packages :-).  But the mere fact that I instinctively
> consider them to be somewhat separate developer communities from Emacs
> itself may be partly an artifact of our having been on bzr for so
> long.

Emacs maintainers and Carsten should really have the last word on
this, but directly hacking Org from within Emacs would be a plus.

With a tighter release schedule, we will all gain from this: users
(no more separate install) and Emacs (expose Org contributors to Emacs
directly.)

-- 
 Bastien

Re: Apologia for bzr

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> All the terminology that's referred to in the git command man pages is
>> defined in one central place, the gitglossary(7) man page.
>
> First, there are no references to glossary in these places, and, as
> you know well, references in man pages are a PITA to use (unlike in
> Info).

On my Gentoo system, git installed an info manual.  But honestly, that's
just an index of the man pages but still better to browse than the
normal man pages, e.g., you have `l' to jump back to where you were
previously etc.

> More importantly, the glossary, at least git's glossary, is not going
> to help here.  Let's take this example I showed earlier:
>
>   --reuse-message=<commit> 
>     Take an existing commit object, and reuse the log message and the
>     authorship information (including the timestamp) when creating the
>     commit.
>
> Clearly, what I need to know here, and is never explained, is how do I
> _reference_ a commit object.  Now, here's what the glossary tells me:
>
>   commit object 
>        An object which contains the information about a particular
>        revision, such as parents, committer, author, date and the tree
>        object which corresponds to the top directory of the stored
>        revision.
>
> I hope you will agree with me that after reading this, I'm none the
> wiser.

Yes, true, but the gittutorial(7) does explain that.  And searching for
"git how to reference a commit" brings me to the git book's Revision
Selection chapter which discusses that in utmost details.

So the man pages could be better, but there are tons of additional
resources you can consult that are easy to find and probably better to
grasp.

Bye,
Tassilo

Re: Apologia for bzr

[Ulrich Mueller]

>>>>> On Fri, 03 Jan 2014, Tassilo Horn wrote:

> On my Gentoo system, git installed an info manual. But honestly,
> that's just an index of the man pages [...]

Git should install the following two nodes:

* Git: (git).                   A fast distributed revision control system
* Git Man Pages: (gitman).      Manual pages for Git revision control system

The first is the Git User Manual, the second a collection of the man
pages. Is the first one missing on your system?

Ulrich

Re: Apologia for bzr

[Tassilo Horn]

Ulrich Mueller <ulm@gentoo.org> writes:

Hi Ulrich,

>> On my Gentoo system, git installed an info manual. But honestly,
>> that's just an index of the man pages [...]
>
> Git should install the following two nodes:
>
> * Git: (git).                   A fast distributed revision control system
> * Git Man Pages: (gitman).      Manual pages for Git revision control system
>
> The first is the Git User Manual, the second a collection of the man
> pages. Is the first one missing on your system?

Ups, no.  I've only missed it so far. ;-)

BTW, another great git resource for getting an overview of git's
commands once you know the basic concepts is the git cheatsheet at

  http://ndpsoftware.com/git-cheatsheet.html

Bye,
Tassilo

Re: Apologia for bzr

[Eli Zaretskii]

> Date: Fri, 3 Jan 2014 21:02:55 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, esr@thyrsus.com, kfogel@red-bean.com,
>         emacs-devel@gnu.org
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> >>>>> On Fri, 03 Jan 2014, Tassilo Horn wrote:
> 
> > On my Gentoo system, git installed an info manual. But honestly,
> > that's just an index of the man pages [...]
> 
> Git should install the following two nodes:
> 
> * Git: (git).                   A fast distributed revision control system
> * Git Man Pages: (gitman).      Manual pages for Git revision control system

When you build Git, by default it doesn't build the Info docs.  You
need to insist (with "make info").  So it's a small wonder people
don't have that manual.

Re: Apologia for bzr

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 17:57:19 +0100
> 
> So the man pages could be better, but there are tons of additional
> resources you can consult that are easy to find and probably better to
> grasp.

I guess we should stop investing so much effort in the Emacs manuals,
then -- there's so much resources out there, let the users look for
them instead.

Re: Apologia for bzr

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> I guess we should stop investing so much effort in the Emacs manuals,
> then -- there's so much resources out there, let the users look for
> them instead.

As already said, man pages are not for learning core concepts of the
tool (except for the specific man pages devoted to that purpose, of
course.) You can't expect to edit some files on a source tree versioned
under git and then do a `git help commit' and learn how to commit your
changes right away, because git uses some concepts which are not shared
by other VCS you might know. You need to understand how git works first
and learn the terminology.

Really, I see no difference with any other non-trivial software package.
It is not as if the output of C-h k M-w is self-contained and free of
Emacs-specific jargon.

Re: Apologia for bzr

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Cc: esr@thyrsus.com,  kfogel@red-bean.com,  emacs-devel@gnu.org
>> Date: Fri, 03 Jan 2014 17:57:19 +0100
>> 
>> So the man pages could be better, but there are tons of additional
>> resources you can consult that are easy to find and probably better to
>> grasp.
>
> I guess we should stop investing so much effort in the Emacs manuals,
> then -- there's so much resources out there, let the users look for
> them instead.

That's not what I was saying.  Clearly, precise, up-to-date and
comprehensible first-party documentation is preferrable over third-party
documentation.  No doubt about that.

But given its large user base, git has the luxury that many people are
willing to support it by writing additional docs.  For example, the Git
Book is maintained and updated as a community effort (and completely
translated into 10 different languages with 19 more on-going translation
efforts).  Although it's not part of the official documentation, it's
still up-to-date and comprehensible for a much larger audience than the
official docs which are precise but not too comprehensible, especially
for newbie.

Anyway, I think we can safely stop this subthread.  I got your point,
and I guess you got mine.

Bye,
Tassilo