bzr is dying; Emacs needs to move

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

[Thien-Thi Nguyen]

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

() esr@thyrsus.com (Eric S. Raymond)
() Thu,  2 Jan 2014 04:53:47 -0500 (EST)

   Sticking to a moribund version-control system will compound and
   exacerbate the project's difficulty in attracting new talent.

It impedes people stuck on old (low spec) computers, too.  For example,
in my adventures w/ git-bzr, i have managed to do the initial clone, but
512M RAM is not enough to achieve the tantalizingly compact footprint
that "git gc --aggressive" purports.  I'm a stubborn fool and will find
a way eventually (suggestions from git-bzr / git experts welcome!), but
it's an unqualified slog that i imagine is just not worth the trouble
for others in similar straits.

-- 
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: bzr is dying; Emacs needs to move

[Bozhidar Batsov]

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

On Thursday, January 2, 2014 at 1:52 PM, Thien-Thi Nguyen wrote:
> () esr@thyrsus.com (mailto:esr@thyrsus.com) (Eric S. Raymond)
> () Thu, 2 Jan 2014 04:53:47 -0500 (EST)
>  
> Sticking to a moribund version-control system will compound and
> exacerbate the project's difficulty in attracting new talent.
>  
> It impedes people stuck on old (low spec) computers, too. For example,
> in my adventures w/ git-bzr, i have managed to do the initial clone, but
> 512M RAM is not enough to achieve the tantalizingly compact footprint
> that "git gc --aggressive" purports. I'm a stubborn fool and will find
> a way eventually (suggestions from git-bzr / git experts welcome!), but
> it's an unqualified slog that i imagine is just not worth the trouble
> for others in similar straits.
>  
>  

I’m using git-bzr myself and one of my computers overheats while doing the initial clone from bzr :-)  
>  
> --  
> 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: text/html, Size: 2000 bytes --]

Re: bzr is dying; Emacs needs to move

[Bozhidar Batsov]

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

I agree with most of the points you make and I’d love for Emacs to adopt git, but judging from the last discussion on the topic a few months ago (http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html), I don’t think that’s going to happen any time soon.

Btw, Richard said then he wanted to give bzr’s maintainer a reasonable amount of time to fix some bugs (or so I recall). If this hasn’t happened - there’s one more argument in favour of using git. Relying on a poorly maintained project is generally worse than relying on a unpopular project.  

--  
Cheers,
Bozhidar


On Thursday, January 2, 2014 at 2:20 PM, Bozhidar Batsov wrote:

> On Thursday, January 2, 2014 at 1:52 PM, Thien-Thi Nguyen wrote:
> > () esr@thyrsus.com (mailto:esr@thyrsus.com) (Eric S. Raymond)
> > () Thu, 2 Jan 2014 04:53:47 -0500 (EST)
> >  
> > Sticking to a moribund version-control system will compound and
> > exacerbate the project's difficulty in attracting new talent.
> >  
> > It impedes people stuck on old (low spec) computers, too. For example,
> > in my adventures w/ git-bzr, i have managed to do the initial clone, but
> > 512M RAM is not enough to achieve the tantalizingly compact footprint
> > that "git gc --aggressive" purports. I'm a stubborn fool and will find
> > a way eventually (suggestions from git-bzr / git experts welcome!), but
> > it's an unqualified slog that i imagine is just not worth the trouble
> > for others in similar straits.
> >  
> >  
> >  
>  
> I’m using git-bzr myself and one of my computers overheats while doing the initial clone from bzr :-)  
> >  
> > --  
> > 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: text/html, Size: 3206 bytes --]

Re: bzr is dying; Emacs needs to move

[Rüdiger Sonderfeld]

On Thursday 02 January 2014 14:20:32 Bozhidar Batsov wrote:
> I’m using git-bzr myself and one of my computers overheats while doing the
> initial clone from bzr :-)

It's certainly something for cold winter nights to utilise your computer as a 
heat source...

Emacsmirror had a repo which could be used to "jump start" git-bzr.  But sadly 
it is now 404: https://github.com/emacsmirror/emacs  I don't know what git-bzr 
exactly needs.  Maybe the official savannah git mirror could provide the 
information for git-bzr.

But overall I think Emacs development should switch to git.

Regards,
Rüdiger

Re: bzr is dying; Emacs needs to move

[Andreas Schwab]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> Maybe the official savannah git mirror could provide the information
> for git-bzr.

It will help seeding with fairly well-packed objects of all the blobs
and trees in the repository (all commit objects will differ, but that's
only a small fraction of the objects).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr is dying; Emacs needs to move

[James Cloos]

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

TN> in my adventures w/ git-bzr, i have managed to do the initial clone,
TN> but 512M RAM is not enough to achieve the tantalizingly compact
TN> footprint that "git gc --aggressive" purports.  I'm a stubborn fool
TN> and will find a way eventually (suggestions from git-bzr / git
TN> experts welcome!),

Rent a large enough cloud box for an hour, do the git-bzr clone and
aggressive gc there, and then rsync the .git directory to your box.
Or tar and wget it.  Once downloaded, git checkout will complete things.

DigitalOcean.com, Atlantic.net, iwStack.com, as well as Goog and Amazon
have suitable offerings which would cost less than USD1 for the hour or
two it would take for the clone and gc.  (A swap file may be needed for
some of the hourly plans to complete the gc.)

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

Re: bzr is dying; Emacs needs to move

[Thien-Thi Nguyen]

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

() James Cloos <cloos@jhcloos.com>
() Thu, 02 Jan 2014 13:15:35 -0500

   > [512M not enough for "git gc --aggressive"]

   Rent a large enough cloud box for an hour, do the git-bzr clone
   and aggressive gc there, and then rsync the .git directory to
   your box.  Or tar and wget it.  Once downloaded, git checkout
   will complete things.

   DigitalOcean.com, Atlantic.net, iwStack.com, as well as Goog
   and Amazon have suitable offerings which would cost less than
   USD1 for the hour or two it would take for the clone and gc.

Thanks for the tip.  Using such services never occurred to me.

   (A swap file may be needed for some of the hourly plans to
   complete the gc.)

Do you happen to know the maximum transient memory usage for
"git gc --aggressive"?

-- 
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: bzr is dying; Emacs needs to move

[James Cloos]

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

TN> Do you happen to know the maximum transient memory usage for
TN> "git gc --aggressive"?

I just tried it in a clone of git://git.savannah.gnu.org/emacs,
which should be similar.

Before the gc, .git/objects used about 1 Gig of disk space, per du(1).

Git gc --aggressive allocated just over 5 (binary) Gig of VM, and
dirtied most of it, to compress 733141 objects, according to top(1).

An 8 Gig VM should do it without paging.
(DO's price for an 8 Gig is 11.9 cents/hr; Atlantic's is about the same.)

The gnu time(1) output is:

	Command being timed: "git gc --aggressive"
	User time (seconds): 7540.15
	System time (seconds): 22.91
	Percent of CPU this job got: 346%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 36:21.75
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 19393776
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 12574
	Minor (reclaiming a frame) page faults: 6147439
	Voluntary context switches: 105240
	Involuntary context switches: 1550786
	Swaps: 0
	File system inputs: 3066072
	File system outputs: 428408
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

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

Re: bzr is dying; Emacs needs to move

[James Cloos]

>>>>> "JC" == James Cloos <cloos@jhcloos.com> writes:

JC> Before the gc, .git/objects used about 1 Gig of disk space, per du(1).

And I forgot to add, after the gc --agressive, du(1) reports 209M.

So, if you have at least 1.5M worth of bandwidth, the clone + gc + download
should fit into one hour of VM time.

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

Re: bzr is dying; Emacs needs to move

[Andreas Schwab]

James Cloos <cloos@jhcloos.com> writes:

>>>>>> "TN" == Thien-Thi Nguyen <ttn@gnu.org> writes:
>
> TN> Do you happen to know the maximum transient memory usage for
> TN> "git gc --aggressive"?
>
> I just tried it in a clone of git://git.savannah.gnu.org/emacs,
> which should be similar.
>
> Before the gc, .git/objects used about 1 Gig of disk space, per du(1).
>
> Git gc --aggressive allocated just over 5 (binary) Gig of VM, and
> dirtied most of it, to compress 733141 objects, according to top(1).

You should not need --aggresssive if you start with a repository that is
already partly packed.  It won't give you the optimal packing, but it
shouldn't differ by much.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bzr is dying; Emacs needs to move

[joakim]

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

> () James Cloos <cloos@jhcloos.com>
> () Thu, 02 Jan 2014 13:15:35 -0500
>
>    > [512M not enough for "git gc --aggressive"]
>
>    Rent a large enough cloud box for an hour, do the git-bzr clone
>    and aggressive gc there, and then rsync the .git directory to
>    your box.  Or tar and wget it.  Once downloaded, git checkout
>    will complete things.
>
>    DigitalOcean.com, Atlantic.net, iwStack.com, as well as Goog
>    and Amazon have suitable offerings which would cost less than
>    USD1 for the hour or two it would take for the clone and gc.
>
> Thanks for the tip.  Using such services never occurred to me.
>
>    (A swap file may be needed for some of the hourly plans to
>    complete the gc.)
>
> Do you happen to know the maximum transient memory usage for
> "git gc --aggressive"?


I have a box at www.verona.se where i could offer such a service free of
charge to emacs devs, if anyone wants it. It sits in my cupboard, but
has 100mbit link.


I already have plenty of emacs stuff on that box.
-- 
Joakim Verona

Re: bzr is dying; Emacs needs to move

[Rüdiger Sonderfeld]

On Friday 03 January 2014 07:15:41 joakim@verona.se wrote:
> I have a box at www.verona.se where i could offer such a service free of
> charge to emacs devs, if anyone wants it. It sits in my cupboard, but
> has 100mbit link.
> 
> 
> I already have plenty of emacs stuff on that box.

As I said, it shouldn't be necessary to do the import all over again every 
time.  The git mirror should be able to provide the additional 
objects/information which git-bzr needs.  Maybe we could contact the git-bzr 
developer for more information.  But emacsmirror used to do exactly that but 
took down the mirror.  I'm not sure exactly why.

I've created an issue for emacsmirror and asked Jonas for comments.

https://github.com/emacsmirror/p/issues/29

(Unless you want to use your box as a cupboard heater, of course.)

Regards
Rüdiger

Re: bzr is dying; Emacs needs to move

[joakim]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> On Friday 03 January 2014 07:15:41 joakim@verona.se wrote:
>> I have a box at www.verona.se where i could offer such a service free of
>> charge to emacs devs, if anyone wants it. It sits in my cupboard, but
>> has 100mbit link.
>> 
>> 
>> I already have plenty of emacs stuff on that box.
>
> As I said, it shouldn't be necessary to do the import all over again every 
> time.  The git mirror should be able to provide the additional 
> objects/information which git-bzr needs.  Maybe we could contact the git-bzr 
> developer for more information.  But emacsmirror used to do exactly that but 
> took down the mirror.  I'm not sure exactly why.
>
> I've created an issue for emacsmirror and asked Jonas for comments.
>
> https://github.com/emacsmirror/p/issues/29
>
> (Unless you want to use your box as a cupboard heater, of course.)

Its cold in Sveden ;)

>
> Regards
> Rüdiger
>

-- 
Joakim Verona

Re: bzr is dying; Emacs needs to move

[Samuel Bronson]

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

> 512M RAM is not enough to achieve the tantalizingly compact footprint
> that "git gc --aggressive" purports.  I'm a stubborn fool and will find

I'm given to understand that "git gc --aggressive" does not actually pack
things more efficiently in practice, and is thus a waste of time, memory,
*and* disk space.

See
http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/

Also note Linus' suggestion to use "git repack" instead, perhaps with more
aggressive options than the defaults.

Re: bzr is dying; Emacs needs to move

[Thien-Thi Nguyen]

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

() Samuel Bronson <naesten@gmail.com>
() Sat, 4 Jan 2014 02:14:04 +0000 (UTC)

   I'm given to understand that "git gc --aggressive" does not actually
   pack things more efficiently in practice, and is thus a waste of
   time, memory, *and* disk space.  See [URL]

IIUC, the criticism w/ "git gc --aggressive" is that it inhibits the
normal incremental (reusing deltas) operation of the underlying repack,
and thus counter-indicated for day-to-day (post init phase) use.

Since i'm still in the init phase, "git gc --aggressive" is fine, in
principle.  (It's the practice, w/ old computer, that's the problem!)

   Also note Linus' suggestion to use "git repack" instead, perhaps with
   more aggressive options than the defaults.

Yes, this did the trick.  Some observations:

 First attempt -- 3h 10m, 1.5G
 $ git repack -a -d -f

 Second attempt -- 11h 55m, 559M
 $ git repack -a -d -f --window=250 --depth=250 --window-memory=200m

Actually, i report only those attempts that completed.  The others
either died or i interrupted out of annoyance w/ swap-disk-grunting.

559M is not optimal, but i (and old computer :-D) can live w/ it.

Next steps:

- Sanity check.  In the repo, i see HEAD is 6f7f591e (2013-12-07)
  w/ title (and entirety of commit message) "Mention bug 16049.".

  Could someone please confirm this exists in their git-bzr repo?

- Investigate "no safeguard against rewriting upstream bzr repo history":
  <http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00098.html>.

  I'd like to determine if the "doesn't work" part lies in bzrlib or
  in git-remote-bzr.  I suspect the latter, since there is no call
  to ‘die’ in that code.  Hmmm, time to snapshot the (relatively)
  svelte repo and see what damage a tweaked git-remote-bzr can do,
  i suppose...

"But ttn, why not just wait for Emacs to move to Git?"  Well, i've
waited many years and that was a suffering.  Playing w/ git-bzr is
another.  Life is such.

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

"No safeguard against rewriting upstream bzr history" (was: bzr is dying; Emacs needs to move)

[Joshua Judson Rosen]

Thien-Thi Nguyen <ttn@gnu.org> writes:
>
> - Investigate "no safeguard against rewriting upstream bzr repo history":
>   <http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00098.html>.
>
>   I'd like to determine if the "doesn't work" part lies in bzrlib or
>   in git-remote-bzr.  I suspect the latter, since there is no call
>   to ‘die’ in that code.  Hmmm, time to snapshot the (relatively)
>   svelte repo and see what damage a tweaked git-remote-bzr can do,
>   i suppose...

If it's true, one could also say that the upstream branches
are misconfigured: if you set "append_revisions_only = True"
in the branch's .bzr/branch/branch.conf, then the bzr
server will enforce that revisions are only ever added to
the left hand side (mainline edge) of the DAG and never
removed (either by uncommitting or by re-orienting the DAG).

In the case where "append_revisions_only = False", then
"bzr push" is allowed to reorient the DAG so that
a different edge becomes the left hand side (which happens
if someone merges trunk down _into their branch_ and then
pushes their branch up), "bzr uncommit" is allowed to
remove revisions, and "bzr push --overwrite" is allowed
to stomp all over things.

When creating new branches, there's an argument to "bzr init"
that sets this option; if you have write access to the upstream
emacs branches through SFTP, you should probably be able to set
options like append_revisions_only on the existing branch by
SFTP'ing up a new branch.conf file.

-- 
"'tis an ill wind that blows no minds."

Re: "No safeguard against rewriting upstream bzr history"

[Glenn Morris]

Joshua Judson Rosen wrote:

> if you set "append_revisions_only = True" in the branch's
> .bzr/branch/branch.conf, then the bzr server will enforce that
> revisions are only ever added to the left hand side

We know. The Emacs repo is so configured.
On the rare occasions when really needed, this can be changed by anyone
with write access using `bzr config', as noted in admin/notes/bzr.

Re: "No safeguard against rewriting upstream bzr history"

[Wolfgang Jenkner]

On Sun, Jan 05 2014, Joshua Judson Rosen wrote:

> Thien-Thi Nguyen <ttn@gnu.org> writes:
>>
>> - Investigate "no safeguard against rewriting upstream bzr repo history":
>>   <http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00098.html>.
>>
>>   I'd like to determine if the "doesn't work" part lies in bzrlib or
>>   in git-remote-bzr.  I suspect the latter, since there is no call
>>   to ‘die’ in that code.  Hmmm, time to snapshot the (relatively)
>>   svelte repo and see what damage a tweaked git-remote-bzr can do,
>>   i suppose...
>
> If it's true, one could also say that the upstream branches
> are misconfigured: if you set "append_revisions_only = True"
> in the branch's .bzr/branch/branch.conf, then the bzr
> server will enforce that revisions are only ever added to
> the left hand side (mainline edge) of the DAG and never
> removed (either by uncommitting or by re-orienting the DAG).
[...]
> When creating new branches, there's an argument to "bzr init"
> that sets this option;

Thank you very much for this explanation!  Indeed, with this switch, the
local experiment in

http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00094.html

gives the following:

[1 /tmp]$ bzr init --append-revisions-only trunk
Created a standalone tree (format: 2a)
[2 /tmp]$ cat trunk/.bzr/branch/branch.conf
append_revisions_only = True
[3 /tmp]$ (cd trunk && touch foo && bzr add $_ && bzr commit -m X && bzr log --line)
adding foo
Committing to: /tmp/trunk/
added foo
Committed revision 1.
1: Wolfgang Jenkner 2014-01-05 X
[4 /tmp]$ git clone bzr::trunk local
Cloning into 'local'...
Checking connectivity... done.
[5 /tmp]$ (cd trunk && echo "trunk change" >foo && bzr commit -m A && bzr log --line)
Committing to: /tmp/trunk/
modified foo
Committed revision 2.
2: Wolfgang Jenkner 2014-01-05 A
1: Wolfgang Jenkner 2014-01-05 X
[6 /tmp]$ (cd local && echo "local change" >foo && git commit -a -m B && git log --oneline && git push)
[master d494366] B
 1 file changed, 1 insertion(+)
d494366 B
2fa9952 X
Traceback (most recent call last):
  File "/home/wolfgang/bin/git-remote-bzr", line 947, in <module>
    sys.exit(main(sys.argv))
  File "/home/wolfgang/bin/git-remote-bzr", line 933, in main
    do_export(parser)
  File "/home/wolfgang/bin/git-remote-bzr", line 682, in do_export
    branch.generate_revision_history(revid, marks.get_tip(name))
  File "<string>", line 4, in generate_revision_history_write_locked
  File "/usr/local/lib/python2.7/site-packages/bzrlib/branch.py", line 816, in generate_revision_history
    self.set_last_revision_info(revno, revision_id)
  File "<string>", line 4, in set_last_revision_info_write_locked
  File "/usr/local/lib/python2.7/site-packages/bzrlib/branch.py", line 2524, in set_last_revision_info
    self._check_history_violation(revision_id)
  File "/usr/local/lib/python2.7/site-packages/bzrlib/branch.py", line 2727, in _check_history_violation
    raise errors.AppendRevisionsOnlyViolation(self.user_url)
bzrlib.errors.AppendRevisionsOnlyViolation: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/tmp/trunk/".
[7 /tmp]$ (cd trunk && bzr log --line)
2: Wolfgang Jenkner 2014-01-05 A
1: Wolfgang Jenkner 2014-01-05 X
[8 /tmp]$ (cd trunk && bzr status)
[9 /tmp]$ (cd trunk && bzr diff)
[10 /tmp]$ 

So part of the bzrlib safeguard against rewriting history is actually in
one of the callees of generate_revision_history, while git-remote-bzr
seems to assume that it is all in push_branch.

Wolfgang

Re: "No safeguard against rewriting upstream bzr history"

[Thien-Thi Nguyen]

[-- Attachment #1.1: Type: text/plain, Size: 609 bytes --]

() Wolfgang Jenkner <wjenkner@inode.at>
() Sun, 05 Jan 2014 19:38:18 +0100

   So part of the bzrlib safeguard against rewriting history is actually
   in one of the callees of generate_revision_history, while
   git-remote-bzr seems to assume that it is all in push_branch.

Given that the Emacs repo does indeed have that configuration variable
set, sounds like the situation is not actually critical.  Cool.

Nobody has confirmed the sanity check, but w/ this safeguard in place, i
suppose that won't be necessary.  Full speed ahead...

BTW, here is a small patch that makes git-remote-bzr better-behaved:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: git-remote-bzr.diff --]
[-- Type: text/x-diff, Size: 1164 bytes --]

diff -u /etc/alternatives/ /tmp/git-remote-bzr
--- /etc/alternatives/git-remote-bzr	2013-12-07 00:20:48.000000000 +0100
+++ /tmp/git-remote-bzr	2014-01-06 09:18:59.000000000 +0100
@@ -679,7 +679,21 @@
         if ref.startswith('refs/heads/'):
             name = ref[len('refs/heads/'):]
             branch = get_remote_branch(name)
-            branch.generate_revision_history(revid, marks.get_tip(name))
+
+            # This alone is not sufficient:
+            #- branch.generate_revision_history(revid, marks.get_tip(name))
+            #
+            # Instead, we need to also handle the situation
+            # where the remote branch is configured with:
+            #   append_revisions_only = True
+            #
+            # TODO: Refactor the "error message and continue".
+
+            try:
+                branch.generate_revision_history(revid, marks.get_tip(name))
+            except bzrlib.errors.AppendRevisionsOnlyViolation:
+                print "error %s non-fast forward" % ref
+                continue
 
             if name in peers:
                 peer = bzrlib.branch.Branch.open(peers[name],



[-- Attachment #1.3: Type: text/plain, Size: 351 bytes --]

I haven't tested it (yet), but anyway hope it, or its essence, can be
incorporated into the next git-remote-bzr release.

-- 
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: bzr is dying; Emacs needs to move

[Bozhidar Batsov]

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

I agree with most of the points you make and I’d love for Emacs to adopt git, but judging from the last discussion on the topic a few months ago (http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html), I don’t think that’s going to happen any time soon.

Btw, Richard said then he wanted to give bzr’s maintainer a reasonable amount of time to fix some bugs (or so I recall). If this hasn’t happened - there’s one more argument in favour of using git. Relying on a poorly maintained project is generally worse than relying on a unpopular project.  

--  
Cheers,
Bozhidar


On Thursday, January 2, 2014 at 11:53 AM, Eric S. Raymond wrote:

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



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

Re: bzr is dying; Emacs needs to move

[Rüdiger Sonderfeld]

On Thursday 02 January 2014 14:30:31 Bozhidar Batsov wrote:
> Btw, Richard said then he wanted to give bzr’s maintainer a reasonable
> amount of time to fix some bugs (or so I recall). If this hasn’t happened -
> there’s one more argument in favour of using git. Relying on a poorly
> maintained project is generally worse than relying on a unpopular project.

The bug was finally fixed and a new version of bzr released.  But IIRC this 
only happened after Richard contacted the developers.  I'm not sure if other 
bugs get similar attention.

Regards
Rüdiger

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.

[Bastien]

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

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

+1 for using Git.

-- 
 Bastien

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

[Nathan Trapuzzano]

Bastien <bzg@gnu.org> writes:

> +1 for using Git.

Ditto.

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

[Toby Cubitt]

On Thu, Jan 02, 2014 at 11:12:42AM -0500, Nathan Trapuzzano wrote:
> Bastien <bzg@gnu.org> writes:
> 
> > +1 for using Git.
> 
> Ditto.

For what it's worth, I agree with moving to git.

It seems clear that it'll happen eventually, even if the decision gets
postponed again this time. But ESR makes a good case for doing it sooner
rather than later.

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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Jose E. Marchesi]

    
    > Does anyone think we should stay on bzr, or choose a VCS other than
    > git?
    
    +1 for using Git.

Same here.

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

[Ulrich Mueller]

>>>>> On Thu, 02 Jan 2014, Bastien  wrote:

> Karl Fogel <kfogel@red-bean.com> writes:
>> Does anyone think we should stay on bzr, or choose a VCS other than
>> git?

> +1 for using Git.

+1

Using Git would improve my workflow both for maintaining distro
specific patches and for submitting them upstream.

Ulrich

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

[Mitchel Humpherys]

On Thu, Jan 02 2014 at 07:56:34 AM, Bastien <bzg@gnu.org> wrote:
> Karl Fogel <kfogel@red-bean.com> writes:
>
>> Does anyone think we should stay on bzr, or choose a VCS other than
>> git?
>
> +1 for using Git.

+1

I recently submitted my first (trivial) patch to Emacs. It was painful
enough to deter me from making a few other changes that I've wanted to
make recently... In contrast, I shoot off "drive-by" patches to
third-party Elisp projects about once a week because it's dead simple
with Git. I know that I could become proficient in bzr with a little
effort but it's just not worth the time investment since there are only
2 or 3 projects that I care about using bzr, while everyone else is
using git.


-- 
Mitch

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

[Sebastian Wiesner]

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

Am 02.01.2014 22:30 schrieb "Mitchel Humpherys" <mitch.special@gmail.com>:
>
> On Thu, Jan 02 2014 at 07:56:34 AM, Bastien <bzg@gnu.org> wrote:
> > Karl Fogel <kfogel@red-bean.com> writes:
> >
> >> Does anyone think we should stay on bzr, or choose a VCS other than
> >> git?
> >
> > +1 for using Git.
>
> +1
>
> I recently submitted my first (trivial) patch to Emacs. It was painful
> enough to deter me from making a few other changes that I've wanted to
> make recently... In contrast, I shoot off "drive-by" patches to
> third-party Elisp projects about once a week because it's dead simple
> with Git. I know that I could become proficient in bzr with a little
> effort but it's just not worth the time investment since there are only
> 2 or 3 projects that I care about using bzr, while everyone else is
> using git.

+1

That's exactly the situation I found in.  I contributed my first patch some
weeks ago, and found Bazaar alone daunting enough to put me off making any
further contributions.

>
>
> --
> Mitch
>

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

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

[Fabián Ezequiel Gallina]

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

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

I'm +1 to git. Currently a fair amount of third party packages (and even
the GNU ELPA repository) are using git, making it a sensible choice.

--
Regards,
Fabián.

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

[Eric S. Raymond]

Karl Fogel <kfogel@red-bean.com>:
> ESR has graciously offered to be technical lead for such a migration.

Because reposurgeon. I should have known the doom that would fall on 
me when I wrote it - to become the go-to buy for messy repo conversions.
Like groff a couple of weeks ago.

This one *should* be relatively easy, DVCS to DVCS usually is. Cross 
your fingers.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Andreas Schwab]

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

> This one *should* be relatively easy, DVCS to DVCS usually is. Cross 
> your fingers.

There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
to do, if any.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
> to do, if any.

Who owns that mirror?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Andreas Schwab]

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

> Andreas Schwab <schwab@linux-m68k.org>:
>> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
>> to do, if any.
>
> Who owns that mirror?

I'm maintaining the mirroring.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Andreas Schwab <schwab@linux-m68k.org>:
> >> There is already git://git.sv.gnu.org/emacs, so there shouldn't be much
> >> to do, if any.
> >
> > Who owns that mirror?
> 
> I'm maintaining the mirroring.
> 
> Andreas.

As you say, there may be nothing that needs doing other than decommissioning
the bzr repo and changing documentation to point to the git one.

Are you aware of any CVS conversion artifacts that should be cleaned up?  I'm
thinking of, in particular:

1. Unmerged commit cliques.

2. Out-of-place release tags.

3. Fossil CVS commit references in commit comments.

If there is any of this sort of cruft, the time to fix it is before the
git repo goes official.  I have good tools for this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Andreas Schwab]

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

> Are you aware of any CVS conversion artifacts that should be cleaned
> up?

I did a lot of cleanup when I converted the old CVS repository to bzr.
That included stitching in sources of history in other repositories
(even some tla archives), creating merge commits where the commit
message would indicate, removing dummy commits that were created by CVS
due to files appearing on branches.

> I'm thinking of, in particular:
>
> 1. Unmerged commit cliques.

I don't know what that means.

> 2. Out-of-place release tags.

I think I fixed them all up.

> 3. Fossil CVS commit references in commit comments.

I didn't change any of the commit comments, on purpose.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
> 
> > Are you aware of any CVS conversion artifacts that should be cleaned
> > up?
> 
> I did a lot of cleanup when I converted the old CVS repository to bzr.

Great.  Less work for me. Maybe none; that would be nice.  

What did you use for the cleanup? reposurgeon?  Something else? 

> > I'm thinking of, in particular:
> >
> > 1. Unmerged commit cliques.
> 
> I don't know what that means.

Many converters don't do a perfect job of detecting CVS file commit cliques
that ought to be merged to changesets.  The symptom of this is runs of 
single-file commits with identical comments.  One way it can happen is if
the CVS exporter's commit-time-difference window was set too small.

(It has many other uses now, but I originally wrote reposurgeon to make
cleaning up this kind of artifact easy to do.)

> > 2. Out-of-place release tags.
> 
> I think I fixed them all up.

Oh, good.  One less tedious task.
 
> > 3. Fossil CVS commit references in commit comments.
> 
> I didn't change any of the commit comments, on purpose.

That is one philosophy. 

I, on the other hand, have way too much experience with repositories that
have geological strata of crap from multiple previous conversions in
them. My goal that for someone browsing a history I have converted,
the VCS transitions should be *invisible*.

This means:

1. Changing source-system ignore files to target-system conventions, not
just in the head revision but in the entire history.

3. Fixing up commit references in change comments so they are either in
the target system's native format or in a VCS-independent form.

We may decide these things should not be done in this case.  But I have
the tools and experience to do them, and that option should be on the
table.
-- 
		<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 13:06:13 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Karl Fogel <kfogel@red-bean.com>, emacs-devel@gnu.org
> 
> > > 1. Unmerged commit cliques.
> > 
> > I don't know what that means.
> 
> Many converters don't do a perfect job of detecting CVS file commit cliques
> that ought to be merged to changesets.  The symptom of this is runs of 
> single-file commits with identical comments.  One way it can happen is if
> the CVS exporter's commit-time-difference window was set too small.

When Emacs used CVS, we almost never committed several files at once
with the same commit message.  Every file was a separate commit.

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

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> When Emacs used CVS, we almost never committed several files at once
> with the same commit message.  Every file was a separate commit.

That is generally not a problem for convertors, since they have to use a
commit-time window anyway (even if you commit all files with one
command, commit times may still differ, especially for files in separate
directories).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Andreas Schwab]

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

> What did you use for the cleanup? reposurgeon?  Something else? 

I've used my own scripts.

> Many converters don't do a perfect job of detecting CVS file commit cliques
> that ought to be merged to changesets.  The symptom of this is runs of 
> single-file commits with identical comments.  One way it can happen is if
> the CVS exporter's commit-time-difference window was set too small.

I don't think there are any such occurrences left.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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.

vc.el support for staging hunks/files

[João Távora]

> On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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?)

Yuri Khan <yuri.v.khan@gmail.com> writes:
> 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.

+1 for git and +1 for this technique in particular. This has to be the
most useful thing that git brought to the table for me.

I also thought git commit -a would be always what I wanted, but I was
obviously wrong. Now my favourite workflow is to prototype a change with
some initial commits, semantically independent, sometimes even
empty. Then hack away at everything at once like in pre-VCS days. Then
use git add -p (or git gui) to make many "fixup" commits that can be
squashed onto the initial ones first set using `git rebase
--interactive`. Finally, when the stage is set, `git push`.

I admit I also had trouble with the git docs at first, but the "stage""
metaphor couldn't be cleverer.

My question is, since we're on emacs-devel: could vc.el support this
workflow?

* git-add --edit seems to indicate so;

* diff-mode apparently has diff-marker calculation logic built in;

* magit supports it apparently and its git-rebase-mode.el could be used
  independently.

Is there interest in such a feature?

João

Re: vc.el support for staging hunks/files

[Dan Nicolaescu]

joaotavora@gmail.com (João Távora) writes:

>> On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 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?)
>
> Yuri Khan <yuri.v.khan@gmail.com> writes:
>> 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.
>
> +1 for git and +1 for this technique in particular. This has to be the
> most useful thing that git brought to the table for me.
>
> I also thought git commit -a would be always what I wanted, but I was
> obviously wrong. Now my favourite workflow is to prototype a change with
> some initial commits, semantically independent, sometimes even
> empty. Then hack away at everything at once like in pre-VCS days. Then
> use git add -p (or git gui) to make many "fixup" commits that can be
> squashed onto the initial ones first set using `git rebase
> --interactive`. Finally, when the stage is set, `git push`.
>
> I admit I also had trouble with the git docs at first, but the "stage""
> metaphor couldn't be cleverer.
>
> My question is, since we're on emacs-devel: could vc.el support this
> workflow?
>
> * git-add --edit seems to indicate so;
>
> * diff-mode apparently has diff-marker calculation logic built in;
>
> * magit supports it apparently and its git-rebase-mode.el could be used
>   independently.
>

IMHO there would be quite a bit of interest if such a feature was
properly integrated in vc.
You might want to first post the design here before doing any
implementation work..

               

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

glossary terms linked

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-10-29 10:12]:
> >> 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

Thank you, that is great feature.

info+ show buttons with my theme little embossed or opposite of
embossed.

I hope similar enters Emacs to make terminology easier accessible.


-- 
Jean Louis

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

Apologia for CUA mode

[Christophe Poncy]

On 2014-01-04 20:38, Lennart Borgman wrote:
> 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. ;-)

Not all. My mother who never touched a PC in its entire life likes emacs 
as it is :)

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

Re: Apologia for CUA mode

[Lennart Borgman]

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

On Sat, Jan 4, 2014 at 11:09 PM, Christophe Poncy <cp@genium.fr> wrote:

> And (as you probably remember) the problem with that as I see it is the
>>>
>> key bindings. Users expect CUA. ;-)
>>
>
> Not all. My mother who never touched a PC in its entire life likes emacs
> as it is :)
>
>
Either she has a very special talent. Or, perhaps, it is You that she
likes. ;-)

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

CUA mode???

[Joshua Judson Rosen]

David Kastrup <dak@gnu.org> writes:
>
> Tom <adatgyujto@gmail.com> writes:
>
> > Lennart Borgman <lennart.borgman <at> gmail.com> writes:
> >> 
> >> 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".

"copY" and... "Kut" (with a "K" for extra hardness because it's a
destructive operation?)?

Also, didn't cua-mode already `fix' this:

    http://www.gnu.org/software/emacs/manual/html_node/emacs/CUA-Bindings.html

Though that brings me to something that's been bugging me since someone
first told me (last year) that cua-mode had actually gone into emacs:
my recollection from the early 1990s was that the CUA keystrokes for
cut, copy, and paste were *not* C-x, C-c, and C-v; but rather
S-delete, C-insert, and S-insert (respectively). These were the
keystrokes that I remember using in Windows at the time, and
what I've also been using in Emacs and other applications in X11
since about that time, and even what I used in applications on
Mac OS X when I needed to use it just a couple of years ago.

Wikipedia seems to agree with my memory rather than what's in the Emacs
manual:

    https://en.wikipedia.org/wiki/Common_User_Access

Did the CUA spec actually change to use C-x, C-c, C-v at some point, or
is Emacs cua-mode mistaken about which standard it's implementing?

-- 
"'tis an ill wind that blows no minds."

Re: CUA mode???

[Lennart Borgman]

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

On Jan 4, 2014 9:17 PM, "Joshua Judson Rosen" <rozzin@geekspace.com> wrote:
>
>
> Also, didn't cua-mode already `fix' this:
>
>
http://www.gnu.org/software/emacs/manual/html_node/emacs/CUA-Bindings.html
>
> Though that brings me to something that's been bugging me since someone
> first told me (last year) that cua-mode had actually gone into emacs:
> my recollection from the early 1990s was that the CUA keystrokes for
> cut, copy, and paste were *not* C-x, C-c, and C-v; but rather
> S-delete, C-insert, and S-insert (respectively). These were the
> keystrokes that I remember using in Windows at the time, and
> what I've also been using in Emacs and other applications in X11
> since about that time, and even what I used in applications on
> Mac OS X when I needed to use it just a couple of years ago.
>
> Wikipedia seems to agree with my memory rather than what's in the Emacs
> manual:
>
>     https://en.wikipedia.org/wiki/Common_User_Access
>
> Did the CUA spec actually change to use C-x, C-c, C-v at some point, or
> is Emacs cua-mode mistaken about which standard it's implementing?

Ah, so you mean that cua-mode was also badly named in Emacs in should be
renamed? ;-)

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

Re: CUA mode???

[Xue Fuqiao]

On Sun, Jan 5, 2014 at 7:38 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>> Also, didn't cua-mode already `fix' this:
>>
>> http://www.gnu.org/software/emacs/manual/html_node/emacs/CUA-Bindings.html
>>
>> Though that brings me to something that's been bugging me since someone
>> first told me (last year) that cua-mode had actually gone into emacs:
>> my recollection from the early 1990s was that the CUA keystrokes for
>> cut, copy, and paste were *not* C-x, C-c, and C-v; but rather
>> S-delete, C-insert, and S-insert (respectively). These were the
>> keystrokes that I remember using in Windows at the time, and
>> what I've also been using in Emacs and other applications in X11
>> since about that time, and even what I used in applications on
>> Mac OS X when I needed to use it just a couple of years ago.
>>
>> Wikipedia seems to agree with my memory rather than what's in the Emacs
>> manual:
>>
>>     https://en.wikipedia.org/wiki/Common_User_Access
>>
>> Did the CUA spec actually change to use C-x, C-c, C-v at some point, or
>> is Emacs cua-mode mistaken about which standard it's implementing?
>
> Ah, so you mean that cua-mode was also badly named in Emacs in should be
> renamed? ;-)

Eli said that there's more than one interpretation of CUA:
http://lists.gnu.org/archive/html/help-gnu-emacs/2013-04/msg00499.html

-- 
http://www.gnu.org/software/emacs/

Re: CUA mode???

[Lennart Borgman]

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

On Mon, Jan 6, 2014 at 12:15 AM, Xue Fuqiao <xfq.free@gmail.com> wrote:

> On Sun, Jan 5, 2014 at 7:38 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
> >> Also, didn't cua-mode already `fix' this:
> >>
> >>
> http://www.gnu.org/software/emacs/manual/html_node/emacs/CUA-Bindings.html
> >>
> >> Though that brings me to something that's been bugging me since someone
> >> first told me (last year) that cua-mode had actually gone into emacs:
> >> my recollection from the early 1990s was that the CUA keystrokes for
> >> cut, copy, and paste were *not* C-x, C-c, and C-v; but rather
> >> S-delete, C-insert, and S-insert (respectively). These were the
> >> keystrokes that I remember using in Windows at the time, and
> >> what I've also been using in Emacs and other applications in X11
> >> since about that time, and even what I used in applications on
> >> Mac OS X when I needed to use it just a couple of years ago.
> >>
> >> Wikipedia seems to agree with my memory rather than what's in the Emacs
> >> manual:
> >>
> >>     https://en.wikipedia.org/wiki/Common_User_Access
> >>
> >> Did the CUA spec actually change to use C-x, C-c, C-v at some point, or
> >> is Emacs cua-mode mistaken about which standard it's implementing?
> >
> > Ah, so you mean that cua-mode was also badly named in Emacs in should be
> > renamed? ;-)
>
> Eli said that there's more than one interpretation of CUA:
> http://lists.gnu.org/archive/html/help-gnu-emacs/2013-04/msg00499.html
>
> --
> http://www.gnu.org/software/emacs/
>

Yes, but here is the important point from that page:

"The subset of CUA implemented in Microsoft
Windows<http://en.wikipedia.org/wiki/Microsoft_Windows>
 or OSF/Motif <http://en.wikipedia.org/wiki/Motif_(software)> is generally
considered a de facto standard to be followed by any new Unix GUI
environment."

Using the Alt+underlined letter to open a menu is still a problem in Emacs.
(I have, or had, a patch for that, but it was never accepted.)

[-- Attachment #2: Type: text/html, Size: 4242 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.

Apologia for CUA mode (was: Apologia for bzr)

[Christophe Poncy]

On 2014-01-04 16:44, Tom wrote:
> 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.

FWIW, I miss those things outside emacs, it's why I am using firemacs on 
firefox…

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

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

Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

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

What confusion?  Is there really a problem?  Are you sure?

I've been dealing with newbie Emacs questions and confusion
for as long as most of you, and I don't think I have ever
encountered a user who had difficulting understanding what
we mean, once the terms are presented.

IOW, any contact at all with either the Emacs docs or a quick
Q & A has always answered any user questions I've come across
in this regard.  I have never, ever, encountered any
"confusion" here.  There is sometimes confusion elsewhere
(menu structure, keymaps, font-lock-keywords...), but no
confusion about windows and frames, once the terms are
explained.  No confusion, just initial ignorance, which is
not the same thing and which is easily remedied.

Seriously, have any of you encounted a user who could not
understand what an Emacs window and frame are?  Ever?
Really?

It's a faux probleme.  It says more about you who see it as
a problem than it does about any potential Emacs newbies.

And you ain't gonna get no mileage out of making a big
attempt to clothe Emacs in terminology the Emacs-ignorant
will immediately recognize.  There really is a wolf under
those sheepskins - Emacs is a different beast.  Everything
worth its salt has its own jargon.  Including Emacs.

Gratuitous differences in terminology for identical things
are something else.  But (a) that is rare (the Emacs thingies
are not really the same), and (b) even then it is not
important to toe the line.  Especially if the things are
identical, it is easy to learn new terms for them.

Examples of exceptional things that are identical in Emacs,
or nearly so, are "cut" and "paste" operations.  And as
others have already said, it is enough to point out the
Emacs terminology and the correspondences (when there are
close correspondences and not just faux amis) - which we
already do, AFAIK.

If you think that initiation into the ways and jargon of
Emacs is just too darn hard for today's kiddies, I'd say
you're not only pandering (demagogy), you're selling the
kiddies short.  Have confidence.  You learned Emacs, and
no, you ain't no smarter or tougher than they are.

(Now if we just get rid of Emacs, I think that would take
care of most confusion...)

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:

>
> What confusion?  Is there really a problem?  Are you sure?
>
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
>
> The difficulty is not understanding, but rather remembering. "What a h-ll
did they call that?"

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Joel Mccracken]

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

Beyond trying to remember, using current terminology is sends the message that Emacs is old, stubborn, and crufty, which is a problem when trying to introduce new users to Emacs.

On Jan 7, 2014, at 5:30 AM, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> On Tue, Jan 7, 2014 at 8:30 AM, Drew Adams <drew.adams@oracle.com> wrote:
> 
> What confusion?  Is there really a problem?  Are you sure?
> 
> I've been dealing with newbie Emacs questions and confusion
> for as long as most of you, and I don't think I have ever
> encountered a user who had difficulting understanding what
> we mean, once the terms are presented.
> 
> The difficulty is not understanding, but rather remembering. "What a h-ll did they call that?"
> 


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

RE: Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

> Beyond trying to remember, using current terminology is sends
> the message that Emacs is old, stubborn, and crufty, which is a
> problem when trying to introduce new users to Emacs.

No, it does not.  If Emacs were invented from scratch today, it
would still need its own jargon.  Some of the particulars would
no doubt be different, but Emacs would still stand apart in both
behavior and terminology.

Emacs happens to be old.  And it happens to be different.
Being different does not send a message that Emacs is old, or
stubborn, or crufty.  Being old means that it is, well, old.
But that too does not send a message that it is stubborn or
crufty.

You are sending that message, by proposing that the terminology
be updated etc.  Someone new to Emacs and aware of this kind of
discussion can be forgiven for getting the mistaken impression
that Emacs behavior is just the same as other apps but the
terminology is out-of-date and so makes learning it unnecessarily
difficult.  That's the wrong message entirely - quite misleading.

The right takeaway for a new user is that learning Emacs is
learning something new and different - it is not your momma's
editor.  And it rightfully has its own terminology, which you
had better learn also.

The Greek philosopher Proclus records that when Ptolemy asked
if there wasn't perhaps an easier way to learn Emacs than Emacs,
Euclid replied, "Sire, there is no royal road to Emacs."

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 8:06 PM, Drew Adams <drew.adams@oracle.com> wrote:

>
> The right takeaway for a new user is that learning Emacs is
> learning something new and different - it is not your momma's
> editor.  And it rightfully has its own terminology, which you
> had better learn also.
>
>
Did not someone say it was his momma's editor? ;-)
I think you are taking your points too far. For me the problem is how to
make a good road into Emacs for new users. I want a feeling like "this is
what I am used to and now I am glad I discovered the new possibilities". It
should be both familiar and new at the same time.


> The Greek philosopher Proclus records that when Ptolemy asked
> if there wasn't perhaps an easier way to learn Emacs than Emacs,
> Euclid replied, "Sire, there is no royal road to Emacs."
>

There might be some translation error or misunderstanding there. ;-)

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Reitter]

On Jan 7, 2014, at 2:06 PM, Drew Adams <drew.adams@oracle.com> wrote:

>> Beyond trying to remember, using current terminology is sends
>> the message that Emacs is old, stubborn, and crufty, which is a
>> problem when trying to introduce new users to Emacs.
> 
> No, it does not.  If Emacs were invented from scratch today, it
> would still need its own jargon.  Some of the particulars would
> no doubt be different, but Emacs would still stand apart in both
> behavior and terminology.

Yes, but the jargon would not conflict with widely used terminology.  Would you really redefine a common word like "window", and invent another one referring to the established meaning of windows?  

Other things are actually different, and different terms are appropriate. "Mark" comes to mind, or "major" and "minor" modes.

You're right in that Emacs is not yet another editor, and you want to send that message.  But, don't people see this soon enough when they actually use it?

The UI experiment that I have been interested in with Aquamacs, is to allow people to gradually transition from a newbie user to a proficient one with high routinized sequences of actions.  This is actually something that other editors and IDEs can't provide to the extent that Emacs does.  Netbeans, Eclipse, Xcode - they're great IDEs and very integrated, and certainly useful for proficient users, but they're nowhere nearly as efficient as Emacs.

RE: Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

> > If Emacs were invented from scratch today, it
> > would still need its own jargon.  Some of the particulars would
> > no doubt be different, but Emacs would still stand apart in both
> > behavior and terminology.
> 
> Yes, but the jargon would not conflict with widely used terminology.

Preferably, yes; agreed.  Other things being equal...

> Would you really redefine a common word like "window", and invent
> another one referring to the established meaning of windows?

No, I would not.  This is what I meant by "Some of the particulars
would no doubt be different."

> Other things are actually different, and different terms are
> appropriate. "Mark" comes to mind, or "major" and "minor" modes.

Yes, in general.  (Dunno about "mark", but let's not get into
particulars right now.)

> You're right in that Emacs is not yet another editor, and you want
> to send that message.  But, don't people see this soon enough when
> they actually use it?

Yes.  I am not suggesting that that message is not getting across.
You are mistaken that I feel a need to send that message.  My point
was that Emacs behavior is different, and it necessarily has its
own terminology to some extent.  That is not something to be wished
away or papered over.

> The UI experiment that I have been interested in with Aquamacs, is
> to allow people to gradually transition from a newbie user to a
> proficient one with high routinized sequences of actions.  This is
> actually something that other editors and IDEs can't provide to the
> extent that Emacs does.  Netbeans, Eclipse, Xcode - they're great
> IDEs and very integrated, and certainly useful for proficient users,
> but they're nowhere nearly as efficient as Emacs.

Concrete suggestions about that might well be helpful.  So far,
the discussion has just rehashed previous ones.  What you suggest
is not a bad goal, but the starting point should not be to short-sell
newbie Emacs users (not suggesting your approach does that; I don't
know).  They are as bright as past newbies, no doubt.

Yes, they have more experience with other approaches that could
mislead them - Emacs is not often their first editor/UI.  But that
does not mean they cannot "get" Emacs.  What is true today, as it
always has been, is that some effort to learn is needed.  You
cannot just pick up Emacs expecting it to do what you are used to,
without being disappointed or missing the boat.

One has only to look at the questions on a site such as
StackOverflow, not especially those about Emacs, but generally
(and apparently about PHP in particular), to see that some users
expect instant familiarity with a product without any effort - not
even a cursory look at the doc or a Google search.  The SO site
leaders are continually lamenting the poor quality of (some)
questions and askers.  Some people really do expect a royal road
to learning.  Encouraging them in that does not help them or
anyone else.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 9:31 PM, Drew Adams <drew.adams@oracle.com> wrote:

>
> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search.  The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers.  Some people really do expect a royal road
> to learning.  Encouraging them in that does not help them or
> anyone else.
>
>
The main road to learning is probably that it is fun. That is how our
brains work. Learning new names for wellknown things is not that fun. It is
just trivial. (Unless you are learning a new language, of course.)

I would expect Emacs new comers to look for the real interesting things in
Emacs. And those who do that are perhaps those that have most to gain from
Emacs. They might just stop because of the boring trivial things.

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Reitter]

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

On Jan 7, 2014, at 3:31 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Concrete suggestions about that might well be helpful.

I had some suggestions or questions back in 2005 or thereabouts, when I was less familiar with Emacs,
and I asked questions on this mailing list.  Perhaps now the time is better (although I have less time).

Many things are vastly improved from what they were back then - better default key bindings, ELPA, copy&paste with other apps working out of the box, and so on.  

At this time, my concrete suggestion I would have is to make semantic, CEDET and etags work out-of-the-box for all major programming paradigms, and make them work without noticeable performance penalty.  Standard IDEs like Netbeans, Eclipse or Xcode give me that.  Emacs 24 has come a long way, but it's not quite there yet.  For instance, I can enable Semantic from the menu, but then I'd try C-M-/ for a completion, next to [win ...] in nsterm.m, and that doesn't give me all the members of the class of "win", in the correct capitalization.  In .c files, I get at least some helpful echo area messages, but scrolling gets sluggish.  Netbeans doesn't do that.   And it just-in-time compiles, marks syntax errors automatically right in the source code, and so on, and so forth.

The second suggestion is better project management, integrated with Semantic.  Some ingredients, like Speedbar and Desktop, are there, but they do not provide an integrated experience. 

Other people will have other suggestions...

>  What you suggest
> is not a bad goal, but the starting point should not be to short-sell
> newbie Emacs users (not suggesting your approach does that; I don't
> know).  They are as bright as past newbies, no doubt.

Indeed, that's not what I meant.  It's just that even intelligent people prefer to spend their cognitive resources on the actual tasks they are employed to do, or the tasks they intend to do, rather than to learn the tool.  We're in a world where software has become obvious to use, or at least very discoverable.

> You
> cannot just pick up Emacs expecting it to do what you are used to,
> without being disappointed or missing the boat.

The idea in Aquamacs is that you can do that, and transition to faster routines as you go along.
It's probably true that the proportion of highly proficient users is smaller, but the overall number of users is greater.

> One has only to look at the questions on a site such as
> StackOverflow, not especially those about Emacs, but generally
> (and apparently about PHP in particular), to see that some users
> expect instant familiarity with a product without any effort - not
> even a cursory look at the doc or a Google search.  The SO site
> leaders are continually lamenting the poor quality of (some)
> questions and askers. 

Yes, programming has become very much a copy&paste (sorry, kill&yank) effort.  For many programming projects, that is sufficient.  You won't get to hack away at Google, Inc., or at Oracle Corp that way, but that's probably OK. 


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4151 bytes --]

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Tom]

David Reitter <david.reitter <at> gmail.com> writes:
> 
> At this time, my concrete suggestion I would have is to make semantic, CEDET 
and etags work out-of-the-box for all major programming paradigms, and make 
them work without noticeable performance penalty. 

I'd suggest giving some attention to Eclim too. It can do things which
other tools cannot AFAIK. E.g. offering code fixes and stuff. See here:

http://www.skybert.net/emacs/java/

Of course, it requires Eclipse, but it's not necessarily a disadvantage,
because lots of users use Eclipse today and they try emacs beside that.
So it can even be an advantage, because the user can work in eclipse
as usual and at the same time he can work with the same project in
emacs. It makes very easy to try working in emacs, because the user
does not have to create a new environment for developing with emacs,
emacs simply connects to the running eclipse instance.

And Eclim has lots of low hanging fruits, so it can be improved 
with little effort. It only needs some attention, because the current
maintainer said he wouldn't implement stuff he didn't use:

http://fredrik.appelberg.me/2013/06/10/maintainer-blues.html

So a polished/improved Eclim would be very useful for newbie users
even if it's not part of core Emacs, because it makes easy to
try working in emacs.

Here's a list of what Eclim is capable of, and only a fraction of
this is implemented by the emacs interface, though it's not hard
to implement them (it involves only calling the relevant operations
and presenting the results to the user):


Eclipse Projects

Create, update, and delete Eclipse projects.
Easily manage Eclipse .classpath files (support for maven and ivy).
Quickly and easily manage settings globally or on a project basis.

Java

Automatic source code validation (w/ visual marking of errors and warnings).
Context sensitive code completion.
Code correction suggestions with option to apply a suggestion.
Class constructor generation.
Java Bean getter and setter generation.
Generation of delegate methods.
Java source and java doc searching capabilities.
Generate stub methods from implemented interfaces or super classes.
Generate stub methods for junit testing.
Quickly clean and sort imports and easily import new classes.
Automatic generation of logging initialization code, upon first usage of a 
logger.
Javadoc generation for package, class, field, method, etc.
Java regular expression testing.
Support for Checkstyle.
Validation of log4j xml files.

C/C++

Context sensitive code completion.
Searching.
Source code validation.

Css
Context sensitive code completion.
Source code validation.

Html

Context sensitive code completion.
Automatic validation (w/ visual marking of errors and warnings).

Android

Support for creating android projects

Ant

Ant execution from any file.
Context sensitive code completion when editing build files.
Automatic validation of build files (w/ visual marking of errors and warnings).
Quick access to ant documentation.

Maven

Maven execution from any file.
Maven repository searching and ability to add results to pom file.

JavaScript

File validation using jsl.

Php

Code completion.
Searching.
Source code validation.

Python

Context sensitive code completion.
Find element definition support.
Regular expression testing.
Django functionality.
Validation via python compiler, pyflakes, and pylint.

Ruby

Context sensitive code completion.
Searching.
Source code validation.

Xml / Dtd / Xsd

Automatic validation (w/ visual marking of errors and warnings).
Quickly look up element definition from the current xml file's dtd or xsd.
Context sensitive code completion.

And more...


http://eclim.org/features.html

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Joel Mccracken <mccracken.joel@gmail.com> writes:

> Beyond trying to remember, using current terminology is sends the
> message that Emacs is old, stubborn, and crufty, which is a problem
> when trying to introduce new users to Emacs.

Emacs _is_ one of the old great ones.  You are trying to make Gandalf
more popular by plucking his nose hairs.

-- 
David Kastrup

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 8:37 PM, David Kastrup <dak@gnu.org> wrote:

> Joel Mccracken <mccracken.joel@gmail.com> writes:
>
> > Beyond trying to remember, using current terminology is sends the
> > message that Emacs is old, stubborn, and crufty, which is a problem
> > when trying to introduce new users to Emacs.
>
> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
> more popular by plucking his nose hairs.
>
> The great thing lives in its power, not in the nose hairs. Just pick them.
;-)

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

Great Old One?

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
> more popular by plucking his nose hairs.

I could not help reading that as "Emacs is one of the Great Old Ones"

It's...all so obvious now. The keystrokes, the barbarous keystrokes!
Ctrl-Alt-Double-Bucky-PENTAGRAM (U+26E4) - what are these but
invocations of Emacsthulhu who lies sleeping beneath 545 Tech Square,
until the dread day when the stars align and he rises to claim his
dominion?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Great Old One?

[Bob Bobeck]

*crickets*

On 1/7/14, Eric S. Raymond <esr@thyrsus.com> wrote:
> David Kastrup <dak@gnu.org>:
>> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
>> more popular by plucking his nose hairs.
>
> I could not help reading that as "Emacs is one of the Great Old Ones"
>
> It's...all so obvious now. The keystrokes, the barbarous keystrokes!
> Ctrl-Alt-Double-Bucky-PENTAGRAM (U+26E4) - what are these but
> invocations of Emacsthulhu who lies sleeping beneath 545 Tech Square,
> until the dread day when the stars align and he rises to claim his
> dominion?
> --
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
>
>

Re: Great Old One?

[Jordi Gutiérrez Hermoso]

On Tue, 2014-01-07 at 20:20 -0500, Bob Bobeck wrote:
> On 1/7/14, Eric S. Raymond <esr@thyrsus.com> wrote:
> > David Kastrup <dak@gnu.org>:
> >> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
> >> more popular by plucking his nose hairs.
> >
> > I could not help reading that as "Emacs is one of the Great Old Ones"
> >
> > It's...all so obvious now. The keystrokes, the barbarous keystrokes!
> > Ctrl-Alt-Double-Bucky-PENTAGRAM (U+26E4) - what are these but
> > invocations of Emacsthulhu who lies sleeping beneath 545 Tech Square,
> > until the dread day when the stars align and he rises to claim his
> > dominion?

> *crickets*

Nah, I lol'ed. :-)

- Jordi G. H.

Re: Great Old One?

[Jay Belanger]

>> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
>> more popular by plucking his nose hairs.
>
> I could not help reading that as "Emacs is one of the Great Old Ones"
>
> It's...all so obvious now. The keystrokes, the barbarous keystrokes!
> Ctrl-Alt-Double-Bucky-PENTAGRAM (U+26E4) - what are these but
> invocations of Emacsthulhu who lies sleeping beneath 545 Tech Square,
> until the dread day when the stars align and he rises to claim his
> dominion?

Now that it's been pointed out, we should just rename Emacs as CTHULHU:
 CTHULHU's Top Hacks Using Lisp, Horrifying Users
For CTHULHU 25, M-x doctor should be replaced by M-x cthulhu, which no
one should ever call.

Re: Great Old One?

[Joel Mccracken]

I *was* wondering about that Emacs user group at Miskatonic University…


Joel

On Jan 7, 2014, at 9:19 PM, Jay Belanger <jay.p.belanger@gmail.com> wrote:

> 
>>> Emacs _is_ one of the old great ones.  You are trying to make Gandalf
>>> more popular by plucking his nose hairs.
>> 
>> I could not help reading that as "Emacs is one of the Great Old Ones"
>> 
>> It's...all so obvious now. The keystrokes, the barbarous keystrokes!
>> Ctrl-Alt-Double-Bucky-PENTAGRAM (U+26E4) - what are these but
>> invocations of Emacsthulhu who lies sleeping beneath 545 Tech Square,
>> until the dread day when the stars align and he rises to claim his
>> dominion?
> 
> Now that it's been pointed out, we should just rename Emacs as CTHULHU:
> CTHULHU's Top Hacks Using Lisp, Horrifying Users
> For CTHULHU 25, M-x doctor should be replaced by M-x cthulhu, which no
> one should ever call.
> 

Re: Emacs terminology (not again!?) [was: 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. ]]]

    Emacs _is_ one of the old great ones.  You are trying to make Gandalf
    more popular by plucking his nose hairs.

It's not a good analogy.  People can like Gandalf as a character
without having to learn lots of incantations.

Learning Emacs is never going to be easy.  But we might be able
to change Emacs so that learning it is a little less hard,
and that would be a substantial improvement.

-- 
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: Emacs terminology (not again!?) [was: Apologia for bzr]

[Bob Bobeck]

I think it's more like Dumbledwarf. He gets killed in the end. Bwahahhahaha.

On 1/7/14, 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. ]]]
>
>     Emacs _is_ one of the old great ones.  You are trying to make Gandalf
>     more popular by plucking his nose hairs.
>
> It's not a good analogy.  People can like Gandalf as a character
> without having to learn lots of incantations.
>
> Learning Emacs is never going to be easy.  But we might be able
> to change Emacs so that learning it is a little less hard,
> and that would be a substantial improvement.
>
> --
> 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.
>
>
>

Emacs terminology (not again!?) [was: Apologia for bzr]

[Stephen J. Turnbull]

Drew Adams writes:

 > > I think you're right there.  If we just get rid of the word
 > > "window", I think that'll fix most confusions.  
 > 
 > What confusion?  Is there really a problem?  Are you sure?

Agreed.  The important disconnect is between windows and buffers, and
even that isn't so hard for users to figure out.  I think people used
to recent browser interfaces will call buffers "tabs".

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

>
> Agreed.  The important disconnect is between windows and buffers, and
> even that isn't so hard for users to figure out.  I think people used
> to recent browser interfaces will call buffers "tabs".
>

I think that is a good illustration of how confusing different terms can
be... ;-)

"Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
for most new users.

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Yuri Khan]

On Tue, Jan 7, 2014 at 6:27 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> "Tabs" is a UI thing. Calling buffers "tabs" would be very, very confusing
> for most new users.

+1.

The difficulty with Emacs that I had when I was a beginner Emacs user
and still have not completely gotten over, is the relationships
between buffers and windows.

In a typical $another_application, you have at the top level a window
or several windows. Each window may be split into panes, and each pane
may contain several tabs, each tab displaying a document. (In rare
cases, a tab may display a secondary view into a document that is also
displayed by another tab. Opening a secondary view is always a
conscious action on part of the user.) Closing the last view into a
document signals that the user is done with this document — this is
the time to ask any “would you like to save” questions. Otherwise, the
user is free to rearrange tabs between panes and windows. At every
point in time, there is a well-defined spatial position of each
document view — e.g. “the third tab in the upper pane of the window on
my left monitor”.

In Emacs, what you primarily have is a bunch of buffers which exist
without any permanent attachment with the UI. Then, you have frames
that may be split into windows, each window being a view into some
buffer. You cannot meaningfully talk about spatial positions of
buffers — they are essentially “everywhere” or “inside”. Or, if a
buffer is not displayed in any window, it’s “nowhere” and also
“inside”.

The model of Emacs is more flexible, but I find myself struggling with
it because I have to remember that there are hidden buffers and cannot
rely on the spatial model that my mind is accustomed to.

(Curiously, my other always-open application is Firefox that *does*
adhere to the spatial model. I end up opening a single window on each
monitor, and around a dozen tabs in each window. Then I have trouble
locating the tab I need since there are so many of them. So maybe the
problem surfaces when the number of entities exceeds my short-term
memory capacity, regardless of their organization.)

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 >> Agreed.  The important disconnect is between windows and buffers,
 >> and even that isn't so hard for users to figure out.  I think
 >> people used to recent browser interfaces will call buffers "tabs".

 > I think that is a good illustration of how confusing different
 > terms can be... ;-)  "Tabs" is a UI thing. Calling buffers "tabs"
 > would be very, very confusing for most new users.

Agreed.  I'm not suggesting that as Emacs terminology.  I'm saying
that users are going to see buffers as ways to show different content
in the same (GUI) window just like tabs do.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Tue, Jan 7, 2014 at 3:07 PM, Stephen J. Turnbull <stephen@xemacs.org>wrote:

> Lennart Borgman writes:
>  > On Tue, Jan 7, 2014 at 12:13 PM, Stephen J. Turnbull <
> stephen@xemacs.org> wrote:
>
>  >> Agreed.  The important disconnect is between windows and buffers,
>  >> and even that isn't so hard for users to figure out.  I think
>  >> people used to recent browser interfaces will call buffers "tabs".
>
>  > I think that is a good illustration of how confusing different
>  > terms can be... ;-)  "Tabs" is a UI thing. Calling buffers "tabs"
>  > would be very, very confusing for most new users.
>
> Agreed.  I'm not suggesting that as Emacs terminology.  I'm saying
> that users are going to see buffers as ways to show different content
> in the same (GUI) window just like tabs do.
>
> I see. ;-)
In a way, yes. It is a very useful concept. And one of the few things I
think should be presented to new users. The rest should be so familiar so
they should be able to start without knowing more. (If they are just to
Notepad or something similar.

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

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: Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

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

Why not, indeed?  Problem solved.

At ease; false alarm.  Circulez ; il n'y a rien a voir.

(And _you_ are not using That Other Editor why?  Did you perhaps spend
more than 1/2 hour learning This Old Editor?)

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Per Starbäck]

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

2014/1/9 Drew Adams <drew.adams@oracle.com>

> > 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?
>
> Why not, indeed?  Problem solved.
>

Then you are talking about another problem than I am. Functionality (and
attitudes) that turn away those people is indeed a problem for Emacs. It is
sometimes direct, but often indirect (they don't even try Emacs because a
distro maintainer thought that it shouldn't be installed by default). We
want those users. Especially the part of them that would have become
developers.

(And _you_ are not using That Other Editor why?  Did you perhaps spend
> more than 1/2 hour learning This Old Editor?)
>

This seems irrelevant to me. What is your point?

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

RE: Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

>>> 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?
>>
>> Why not, indeed?  Problem solved.
>
> Then you are talking about another problem than I am.  Functionality (and
> attitudes) that turn away those people is indeed a problem for Emacs.

Are you sure that turning away "those people" is a problem for Emacs?

>> (And _you_ are not using That Other Editor why?  Did you perhaps
>> spend more than 1/2 hour learning This Old Editor?)
>
> This seems irrelevant to me. What is your point?

Emacs _is_ a better mousetrap.
http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door

To really appreciate it, some people, if not most, need to give it more
than 1/2 hour, before jumping to the conclusion that it is not worth
their spending more time with it.  As Richard put it, "Learning Emacs is
never going to be easy."  Or as I said:

  Learning Emacs is learning something new and different - it is not
  your momma's editor.  And it rightfully has its own terminology.

"Those people" who don't feel they need to bother - well, they will
either get it later, by way of others, or they will not.  Tant pis.

Emacs losing out because Eclipse or whatever offers more code-refactoring
(or whatever) power, out of the box - that's one thing.  Emacs has room
for improvement in lots of areas, no doubt about that.

But Emacs being "weird" because it uses the word "window" differently -
that's another thing.  I have never encountered a newbie taking Emacs
for a test drive who could not understand, when told what an Emacs
window is.  Have you?

But yes, it might take more than 1/2 hour for Emacs to introduce itself
properly to a user.  ("Hello there, I'm GNU Emacs. Who are you?")

This isn't a cocktail party!  But even if it were, there are some people
who, if given the opportunity, would give up in 5 minutes after being
introduced to the likes of <INSERT HERE your favorite respected
luminaries and Great Ones>, even if they spoke the same language.  Some
people are unfortunately "those people".

Other things being equal, of course we want to make things easy to learn.
Of course we do not want to throw up unnecessary obstacles.  Gratuitous
differences in terminology for identical things should be dealt with -
and they generally are.

  But (a) that is rare (the Emacs thingies are not really the same), and
  (b) even then it is not important to toe the line.  Especially if the
  things are identical, it is easy to learn new terms for them.

The Emacs UI and doc have been dealing with this for almost 4 decades
now.  It does take at least a few minutes and a few examples to get the
notion and behavior of an Emacs "buffer".  Weird!  Not what you're used
to.  Give it a little time.  A better mousetrap - you'll see.

That kind of hand-holding encouragement is fine.  But there is no reason
to underestimate potential users.  Some people will give up without
giving Emacs a chance.  So what?  Others will not - just as you did not.
Why suppose that potential Emacs users are less patient or curious or
intelligent than we are?

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Per Starbäck]

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

2014/1/9 Drew Adams <drew.adams@oracle.com>

> > Then you are talking about another problem than I am.  Functionality (and
> > attitudes) that turn away those people is indeed a problem for Emacs.
>
> Are you sure that turning away "those people" is a problem for Emacs?
>
>
Yes. Any attitude of "it should be hard to learn because the good people
can learn things that are hard to learn" is just contraproductive.


> >> (And _you_ are not using That Other Editor why?  Did you perhaps
> >> spend more than 1/2 hour learning This Old Editor?)
> >
> > This seems irrelevant to me. What is your point?
>
> Emacs _is_ a better mousetrap.
>
> http://en.wikipedia.org/wiki/Build_a_better_mousetrap,_and_the_world_will_beat_a_path_to_your_door
>
> To really appreciate it, some people, if not most, need to give it more
> than 1/2 hour, before jumping to the conclusion that it is not worth
> their spending more time with it.  As Richard put it, "Learning Emacs is
> never going to be easy."  Or as I said:
>
>   Learning Emacs is learning something new and different - it is not
>   your momma's editor.  And it rightfully has its own terminology.
>

Those are not comparable quotes at all. Richard wants Emacs to be easier to
learn for beginners, and I doubt he would write something like your momma
quote. Emacs is the text editor for a GNU system. It shouldn't need some
other text editor for "your momma" besides it, but have Emacs be the
program used for any user who need plain text editing. That Gnome had to
create a new text editor to be the default editor for Gnome was a *big*
setback for Emacs.

To really appreciate any text editor takes time.


> "Those people" who don't feel they need to bother - well, they will
> either get it later, by way of others, or they will not.  Tant pis.
>

That works only if your goal is this elite Emacs. The "right" users will
find it eventually anyway. Not all people have that idea about Emacs.


> But Emacs being "weird" because it uses the word "window" differently -
> that's another thing.  I have never encountered a newbie taking Emacs
> for a test drive who could not understand, when told what an Emacs
> window is.  Have you?
>
>
That's rehashing. It's not about understanding. It's about what impression
you make.


>
> Other things being equal, of course we want to make things easy to learn.
> Of course we do not want to throw up unnecessary obstacles.  Gratuitous
> differences in terminology for identical things should be dealt with -
> and they generally are.
>

So why do you object when people want to deal with this particular
gratuitous difference in terminology? The proposed window->pane change
doesn't affect other stuff. Yes, an Emacs "buffer" for instance is an Emacs
concept that you have to learn because it's different from what you've used
elsewhere, but that's not part of this at all.


> That kind of hand-holding encouragement is fine.  But there is no reason
> to underestimate potential users.  Some people will give up without
> giving Emacs a chance.  So what?  Others will not - just as you did not.
> Why suppose that potential Emacs users are less patient or curious or
> intelligent than we are?
>

My using Emacs is irrelevant. One reason is that I learned (Teco) Emacs in
the 1980s, when expectations on how to learn programs were very different
from now, and with not really any other text editors to choose from anyway.
Another is that the main reason I'm using (GNU) Emacs now is that it's the
editor of the GNU system. If GNU had gone with something else I would
probably have started using that instead, even though that would have been
a much bigger transition than going from one Emacs to another.

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Per Starbäck <per@starback.se> writes:

> 2014/1/9 Drew Adams <drew.adams@oracle.com>
>
>> > Then you are talking about another problem than I am.  Functionality (and
>> > attitudes) that turn away those people is indeed a problem for Emacs.
>>
>> Are you sure that turning away "those people" is a problem for Emacs?
>>
> Yes. Any attitude of "it should be hard to learn because the good
> people can learn things that are hard to learn" is just
> contraproductive.

It's more like "it's unavoidable to provide difficulties to learning
because it can do a lot, and when a lot is easily accessible, you'll
have stuff getting in your hair accidentally".

Musicians learn their instruments, craftsmen learn their tools.
Unfretted bowed string instruments remain a favorite even though the
possibilities for producing wrong notes or sounds that cannot in good
conscience even be called "tones" are staggering when compared to, say,
a piano.  Attempts to cut down on variables the player can get wrong,
like the hurdy gurdy, did not really take off.

A programmer will spend most of his life interacting with an editor and
texts.

> Those are not comparable quotes at all. Richard wants Emacs to be
> easier to learn for beginners, and I doubt he would write something
> like your momma quote.

A carving knife with an exploding handle is not going to be popular.
But you won't be able to sell one with a blunt edge "for safety" either.
Within the variables, one wants to make things as simple as possible but
not simpler.

-- 
David Kastrup

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Tom]

David Kastrup <dak <at> gnu.org> writes:
> 
> It's more like "it's unavoidable to provide difficulties to learning
> because it can do a lot, and when a lot is easily accessible, you'll
> have stuff getting in your hair accidentally".

Arbitrary roadblocks can be removed, though.

For example, yank is not a superior term to paste, so paste could be
used instead. One unnecessary difference less. And it is only one example,
there are others.

Emacs provides enough material to learn without these arbitrary (legacy)
differences, so these should be eliminated where possible.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Tom <adatgyujto@gmail.com> writes:

> David Kastrup <dak <at> gnu.org> writes:
>> 
>> It's more like "it's unavoidable to provide difficulties to learning
>> because it can do a lot, and when a lot is easily accessible, you'll
>> have stuff getting in your hair accidentally".
>
> Arbitrary roadblocks can be removed, though.
>
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less.

You mean, unnecessary similarity.  This has a C-y keyboard binding, and
vi uses y and Y bindings for yanking as well.

> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.

The problem is that they are not "arbitrary" but deeply ingrained into
the choice of keyboard sequences.  And C-x and C-c are pretty much the
most reliably accessible control characters, so they make good sense for
starting multiple keystroke sequences.

What _is_ somewhat annoying in contrast is the positioning of C-b C-n
C-p and C-f.  The hjkl sequences of vi or C-s C-x C-e C-d sequences of
WordStar make more sense.

-- 
David Kastrup

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Davis Herring]

>> For example, yank is not a superior term to paste, so paste could be
>> used instead. One unnecessary difference less.
> 
> You mean, unnecessary similarity.  This has a C-y keyboard binding, and
> vi uses y and Y bindings for yanking as well.

Except that "yank" means "copy" in vi, not "paste".  (This is the source
of most confusion I see about the word.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Davis Herring <herring@lanl.gov> writes:

>>> For example, yank is not a superior term to paste, so paste could be
>>> used instead. One unnecessary difference less.
>> 
>> You mean, unnecessary similarity.  This has a C-y keyboard binding, and
>> vi uses y and Y bindings for yanking as well.
>
> Except that "yank" means "copy" in vi, not "paste".

Uh yeah, forgot about that...

> (This is the source of most confusion I see about the word.)

-- 
David Kastrup

RE: Emacs terminology (not again!?) [was: Apologia for bzr]

[Drew Adams]

> Arbitrary roadblocks can be removed, though.

I said as much:

  Gratuitous differences in terminology for identical things
  are something else.  But (a) that is rare (the Emacs thingies
  are not really the same), and (b) even then it is not
  important to toe the line.  Especially if the things are
  identical, it is easy to learn new terms for them.

IOW, the truly arbitrary differences are rare and not a problem.
Learning Emacs is hard, but not because of them.
 
> For example, yank is not a superior term to paste, so paste could be
> used instead. One unnecessary difference less. And it is only one
> example, there are others.
> 
> Emacs provides enough material to learn without these arbitrary
> (legacy) differences, so these should be eliminated where possible.

To repeat (you might want to read the thread):

  Examples of exceptional things that are identical in Emacs,
  or nearly so, are "cut" and "paste" operations.  And as
  others have already said, it is enough to point out the
  Emacs terminology and the correspondences (when there are
  close correspondences and not just faux amis) - which we
  already do, AFAIK.

We already make clear in the menus and doc that "yank" means
something very similar to "paste".

And (to repeat, again) far more importantly: this is NOT a
point of "confusion" for newbies.

Initial ignorance, yes. But the slightest contact with the
Emacs docs or google or a quick Q & A has always been enough to
let newbies know what "yank" means.  I have never seen anyone
become "confused" after they were introduced to the term "yank".

This is simply a non-problem.  But it gets rehashed here every
so often.

NOT because newbies say they are confused and don't get it.
But only because some well meaning soles here get the bright
idea that this must be confusing to new arrivals and that if
this important obstacle were removed then Emacs would have a
brighter future.

This essentially short-sells newbies, and touches on demagogy.
_You_ learned "yank".  Did you stay up at night in turmoil,
trying to grasp its meaning?  No.  Don't you think that other
newbies are just as bright as you were?  Please, think about it.

Re: Emacs terminology (not again!?) [was: 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. ]]]

Emacs is never going to be as easy to learn as simple
editors, because ease of learning is not its priority.
The priority is effective editing for people willing to learn.
We won't sacrifice that goal for ease of learning.

However, when we can make Emacs easier to learn
at the cost of only _development work_, with no sacrifice in
the principal goal, why not do it?

-- 
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: Emacs terminology (not again!?) [was: Apologia for bzr]

[Per Starbäck]

Richard wrote:

> Emacs is never going to be as easy to learn as simple
> editors, because ease of learning is not its priority.
> The priority is effective editing for people willing to learn.
> We won't sacrifice that goal for ease of learning.

I find this remark about "simple editors" interesting, not just in
terms of Emacs, but of the
whole GNU system. I have always thought of GNU Emacs as *the* editor
in GNU, that is
the default editor. Do you think a GNU system ideally instead should
have some other
("simple") editor as the default editor? And that using Emacs should
be an active choice for
those who are ready to learn something more powerful? This is news to
me in that case.

I still think Emacs should be *the* editor in GNU, and that it is
perfectly possible to have it
like that without sacrificing the goal of effective editing. New users
that only have used at
most simple text editors don't really need or expect much in my
experience. They type text, move around with scrolling wheel and arrow
keys, and look for anything else in toolbars
and menus. They can certainly do that in Emacs.

(What's the point of them doing this in Emacs instead of in a simple
text editor? Because
some of them will become power users, and then they'll already be in
Emacs when they
start looking for more functionality. It's also a point that they can
be thought of as doing
their stuff in Emacs, because then distribution maintainers are more
likely to steer users
into using Emacs. It's not as if all new users make a choice between a
"simple" and a
"powerful" editor, but most of them will use whatever is the default
one on their system, at
least in the beginning, not knowing about the alternatives, and I
think several GNU/Linux
distributions currently don't install Emacs by default at all.)

> However, when we can make Emacs easier to learn
> at the cost of only _development work_, with no sacrifice in
> the principal goal, why not do it?

I agree. But there is another cost as well, which I think is what we
much more often hear
experienced users object to, namely adjustment costs *for them*.

I like the suggestion of renaming "window" into "pane". It removes one part of
(nowadays) peculiar terminology without big adjustment costs at all
(because of aliases
that would exist).

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Per Starbäck <per@starback.se> writes:

> Richard wrote:
>
>> Emacs is never going to be as easy to learn as simple
>> editors, because ease of learning is not its priority.
>> The priority is effective editing for people willing to learn.
>> We won't sacrifice that goal for ease of learning.
>
> I find this remark about "simple editors" interesting, not just in
> terms of Emacs, but of the whole GNU system. I have always thought of
> GNU Emacs as *the* editor in GNU, that is the default editor. Do you
> think a GNU system ideally instead should have some other ("simple")
> editor as the default editor? And that using Emacs should be an active
> choice for those who are ready to learn something more powerful? This
> is news to me in that case.

That's like music instruments that are missing notes to make them
"simpler to learn".  It will always come to bite you eventually.

-- 
David Kastrup

Re: Emacs terminology (not again!?)

[Glenn Morris]

Per Starbäck wrote:

> I have always thought of GNU Emacs as *the* editor in GNU, that is the
> default editor. Do you think a GNU system ideally instead should have
> some other ("simple") editor as the default editor?

If GNU has a default editor, I guess it is the default GNOME one, gedit.
It advertises itself as "aiming at simplicity and ease of use".

Re: Emacs terminology (not again!?)

[Lennart Borgman]

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

On Sat, Jan 18, 2014 at 1:11 AM, Glenn Morris <rgm@gnu.org> wrote:

> Per Starbäck wrote:
>
> > I have always thought of GNU Emacs as *the* editor in GNU, that is the
> > default editor. Do you think a GNU system ideally instead should have
> > some other ("simple") editor as the default editor?
>
> If GNU has a default editor, I guess it is the default GNOME one, gedit.
> It advertises itself as "aiming at simplicity and ease of use".
>
>
Why was gedit developed? It looks advanced to me. (I have never used it.)
Why was not Emacs used as a basis for gedit?

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

Re: Emacs terminology (not again!?)

[Daniel Colascione]

On 01/17/2014 05:47 PM, Lennart Borgman wrote:
> On Sat, Jan 18, 2014 at 1:11 AM, Glenn Morris <rgm@gnu.org
> <mailto:rgm@gnu.org>> wrote:
>
>     Per Starbäck wrote:
>
>      > I have always thought of GNU Emacs as *the* editor in GNU, that
>     is the
>      > default editor. Do you think a GNU system ideally instead should have
>      > some other ("simple") editor as the default editor?
>
>     If GNU has a default editor, I guess it is the default GNOME one, gedit.
>     It advertises itself as "aiming at simplicity and ease of use".
>
>
> Why was gedit developed? It looks advanced to me. (I have never used
> it.) Why was not Emacs used as a basis for gedit?

What does C-s do in Emacs? What do most novice users expect C-s to do? 
In order to use Emacs as a base for gedit, Emacs would have had to have 
been warped beyond all recognition. Emacs is a great environment, but 
let's not pretend that it's what users migrating from proprietary 
desktop operating systems should face when trying to edit a simple 
cookie recipe for themselves should have to face.

Re: Emacs terminology (not again!?)

[Lennart Borgman]

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

On Sat, Jan 18, 2014 at 2:59 AM, Daniel Colascione <dancol@dancol.org>wrote:

> On 01/17/2014 05:47 PM, Lennart Borgman wrote:
>
>> On Sat, Jan 18, 2014 at 1:11 AM, Glenn Morris <rgm@gnu.org
>>  <mailto:rgm@gnu.org>> wrote:
>>
>>     Per Starbäck wrote:
>>
>>      > I have always thought of GNU Emacs as *the* editor in GNU, that
>>     is the
>>      > default editor. Do you think a GNU system ideally instead should
>> have
>>      > some other ("simple") editor as the default editor?
>>
>>     If GNU has a default editor, I guess it is the default GNOME one,
>> gedit.
>>     It advertises itself as "aiming at simplicity and ease of use".
>>
>>
>> Why was gedit developed? It looks advanced to me. (I have never used
>> it.) Why was not Emacs used as a basis for gedit?
>>
>
> What does C-s do in Emacs? What do most novice users expect C-s to do? In
> order to use Emacs as a base for gedit, Emacs would have had to have been
> warped beyond all recognition. Emacs is a great environment, but let's not
> pretend that it's what users migrating from proprietary desktop operating
> systems should face when trying to edit a simple cookie recipe for
> themselves should have to face.
>


Wouldn't you still have recognized the elisp? ;-)

I would have been much more comfortable with Emacs as the basis for gedit.
Emacs was made to be customize-able, but somehow it still failed to form
the basis for gedit. Is not that a bit unfortunate? (Maybe not, but what
about the future of Emacs then?)

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

Re: Emacs terminology (not again!?)

[Daniel Colascione]

On 01/17/2014 06:59 PM, Lennart Borgman wrote:
> On Sat, Jan 18, 2014 at 2:59 AM, Daniel Colascione <dancol@dancol.org
> <mailto:dancol@dancol.org>> wrote:
>     What does C-s do in Emacs? What do most novice users expect C-s to
>     do? In order to use Emacs as a base for gedit, Emacs would have had
>     to have been warped beyond all recognition. Emacs is a great
>     environment, but let's not pretend that it's what users migrating
>     from proprietary desktop operating systems should face when trying
>     to edit a simple cookie recipe for themselves should have to face.
>
> Wouldn't you still have recognized the elisp? ;-)
>
> I would have been much more comfortable with Emacs as the basis for
> gedit. Emacs was made to be customize-able, but somehow it still failed
> to form the basis for gedit. Is not that a bit unfortunate? (Maybe not,
> but what about the future of Emacs then?)

Parts of Emacs are very rigid. Try making a mode that allows point to be 
off-screen while scrolling like it can be in most other editors.

Bear in mind also that when gedit was new, Emacs didn't have 
transient-mark-mode or shift-marking on by default and it didn't support 
bidirectional text. The Emacs configuration system is also completely 
different. Would you have integrated customize with gconf? How?

Re: Emacs terminology (not again!?)

[Eli Zaretskii]

> Date: Fri, 17 Jan 2014 19:02:53 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: Per Starbäck <per@starback.se>,
> 	"Richard M. Stallman" <rms@gnu.org>, David Kastrup <dak@gnu.org>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Try making a mode that allows point to be off-screen while scrolling
> like it can be in most other editors.

It is a common misconception that Emacs cannot do this.  It can.  How
do you think it pulls the trick of allowing you to scroll pixel-wise
through a very large image?

It is a UI design decision in Emacs to always show point on screen.
But nothing prevents us from writing a mode that leaves point off
screen, or even abandoning that decision if we want (and I'm not
saying we do).  The infrastructure is there, check out the vscroll
thingy and window-vscroll.

Re: Emacs terminology (not again!?)

[Daniel Colascione]

On 01/18/2014 12:34 AM, Eli Zaretskii wrote:
>> Date: Fri, 17 Jan 2014 19:02:53 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> Cc: Per Starbäck <per@starback.se>,
>> 	"Richard M. Stallman" <rms@gnu.org>, David Kastrup <dak@gnu.org>,
>> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>
>> Try making a mode that allows point to be off-screen while scrolling
>> like it can be in most other editors.
>
> It is a common misconception that Emacs cannot do this.  It can.  How
> do you think it pulls the trick of allowing you to scroll pixel-wise
> through a very large image?

Thanks. I never use Emacs to view images, so I didn't know we could do that.

> It is a UI design decision in Emacs to always show point on screen.
> But nothing prevents us from writing a mode that leaves point off
> screen, or even abandoning that decision if we want (and I'm not
> saying we do).  The infrastructure is there, check out the vscroll
> thingy and window-vscroll.

Interesting. I may have to play with this functionality more after the 
feature freeze. Is (set-window-vscroll nil 500 t) supposed to move the 
window viewport? I didn't see anything change when I tried it in a quick 
test.

Re: Emacs terminology (not again!?)

[Eli Zaretskii]

> Date: Sat, 18 Jan 2014 00:53:50 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: lennart.borgman@gmail.com, per@starback.se, rms@gnu.org, dak@gnu.org, 
>  emacs-devel@gnu.org
> 
> Is (set-window-vscroll nil 500 t) supposed to move the window
> viewport?

Yes and now.  As I said, Emacs currently deliberately resists this,
except where we explicitly allow it.

> I didn't see anything change when I tried it in a quick test.

See line-move-partial in simple.el for some enlightenment.

Note that an editor that allows point to be off screen needs a lot of
supporting functionality to make this a really useful feature.

Re: Emacs terminology (not again!?)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 17 Jan 2014 19:02:53 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> Cc: Per Starbäck <per@starback.se>,
>> 	"Richard M. Stallman" <rms@gnu.org>, David Kastrup <dak@gnu.org>,
>> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> 
>> Try making a mode that allows point to be off-screen while scrolling
>> like it can be in most other editors.
>
> It is a common misconception that Emacs cannot do this.  It can.  How
> do you think it pulls the trick of allowing you to scroll pixel-wise
> through a very large image?
>
> It is a UI design decision in Emacs to always show point on screen.
> But nothing prevents us from writing a mode that leaves point off
> screen, or even abandoning that decision if we want (and I'm not
> saying we do).  The infrastructure is there, check out the vscroll
> thingy and window-vscroll.

That scrolls "graphically" (no idea whether it works on text terminals):
basically it displaces your screen window by a given distance.  There is
no concept of a "window start" in terms of a text position that can move
away from point, and no real way to implement that.

Also I don't think you can mouse-mark a vscrolled off-screen region
(which would require not setting point when drag-marking a region, but
that seems conceivable) and paste it somewhere afterwards.

It would be possible to experiment around with some of those things.
Judging from my experience with pre-21.1 code (in connection with
preview-latex), this would lead to quite a number of problem reports,
just because it is an area that has been minimally exercised.  Nothing
wrong with that: cleaning out bugs is always a good idea.  But it means
that anybody experimenting with user interface design around that
functionality would be well-advised to compile Emacs from Git and be in
close communication with the developer list.  Even when "nominally"
Emacs has all the functionality he'll be needing.

-- 
David Kastrup

Re: Emacs terminology (not again!?)

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 18 Jan 2014 09:55:13 +0100
> 
> > It is a UI design decision in Emacs to always show point on screen.
> > But nothing prevents us from writing a mode that leaves point off
> > screen, or even abandoning that decision if we want (and I'm not
> > saying we do).  The infrastructure is there, check out the vscroll
> > thingy and window-vscroll.
> 
> That scrolls "graphically"

Yes, I don't see how this is important for the issue at hand.  On a
text terminal, each character counts as a single pixel.

> (no idea whether it works on text terminals):

It doesn't currently, but that's just because no one bothered to
implement that.

> basically it displaces your screen window by a given distance.

Yes.

> There is no concept of a "window start" in terms of a text position
> that can move away from point

A window start is just a buffer position, so I'm not following your
argument here.

> and no real way to implement that.

??? Why not?  Perhaps you mean no way to implement that easily, or
maybe in Lisp alone.

> Also I don't think you can mouse-mark a vscrolled off-screen region
> (which would require not setting point when drag-marking a region, but
> that seems conceivable) and paste it somewhere afterwards.

Indeed, exposing such functionality will need a lot of supporting code
and features.  But that happens with every such endeavor: e.g., when I
introduced menus on a TTY, quite a few of the changes I needed were
because some places hard-coded the assumption that TTYs cannot
possibly have any menus.  Simply lifting that condition was all that
was needed.

> It would be possible to experiment around with some of those things.
> Judging from my experience with pre-21.1 code (in connection with
> preview-latex), this would lead to quite a number of problem reports,
> just because it is an area that has been minimally exercised.  Nothing
> wrong with that: cleaning out bugs is always a good idea.  But it means
> that anybody experimenting with user interface design around that
> functionality would be well-advised to compile Emacs from Git and be in
> close communication with the developer list.  Even when "nominally"
> Emacs has all the functionality he'll be needing.

Very true.

Re: Emacs terminology (not again!?)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 18 Jan 2014 09:55:13 +0100
>> 
>> > It is a UI design decision in Emacs to always show point on screen.
>> > But nothing prevents us from writing a mode that leaves point off
>> > screen, or even abandoning that decision if we want (and I'm not
>> > saying we do).  The infrastructure is there, check out the vscroll
>> > thingy and window-vscroll.
>> 
>> That scrolls "graphically"
>
> Yes, I don't see how this is important for the issue at hand.  On a
> text terminal, each character counts as a single pixel.
>
>> (no idea whether it works on text terminals):
>
> It doesn't currently, but that's just because no one bothered to
> implement that.
>
>> basically it displaces your screen window by a given distance.
>
> Yes.
>
>> There is no concept of a "window start" in terms of a text position
>> that can move away from point
>
> A window start is just a buffer position, so I'm not following your
> argument here.
>
>> and no real way to implement that.
>
> ??? Why not?  Perhaps you mean no way to implement that easily, or
> maybe in Lisp alone.

If the task is "let the window start with the given buffer position even
if this makes point go off-screen", a reasonably simple task
description, window-vscroll does not seem like a useful tool for that.

-- 
David Kastrup

Re: Emacs terminology (not again!?)

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 18 Jan 2014 12:01:21 +0100
> 
> >> There is no concept of a "window start" in terms of a text position
> >> that can move away from point
> >
> > A window start is just a buffer position, so I'm not following your
> > argument here.
> >
> >> and no real way to implement that.
> >
> > ??? Why not?  Perhaps you mean no way to implement that easily, or
> > maybe in Lisp alone.
> 
> If the task is "let the window start with the given buffer position even
> if this makes point go off-screen", a reasonably simple task
> description, window-vscroll does not seem like a useful tool for that.

Maybe not.  I'm just saying that there's no relation between point and
window-start that is somehow hardcoded in the design.  I'm also saying
that window-vscroll and its supporting code is evidence how we can
show stuff on screen without showing point.

Re: Emacs terminology (not again!?)

[Lennart Borgman]

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

On Sat, Jan 18, 2014 at 4:02 AM, Daniel Colascione <dancol@dancol.org>wrote:

> On 01/17/2014 06:59 PM, Lennart Borgman wrote:
>
>> On Sat, Jan 18, 2014 at 2:59 AM, Daniel Colascione <dancol@dancol.org
>>  <mailto:dancol@dancol.org>> wrote:
>>     What does C-s do in Emacs? What do most novice users expect C-s to
>>     do? In order to use Emacs as a base for gedit, Emacs would have had
>>     to have been warped beyond all recognition. Emacs is a great
>>     environment, but let's not pretend that it's what users migrating
>>     from proprietary desktop operating systems should face when trying
>>     to edit a simple cookie recipe for themselves should have to face.
>>
>> Wouldn't you still have recognized the elisp? ;-)
>>
>> I would have been much more comfortable with Emacs as the basis for
>> gedit. Emacs was made to be customize-able, but somehow it still failed
>> to form the basis for gedit. Is not that a bit unfortunate? (Maybe not,
>> but what about the future of Emacs then?)
>>
>
> Parts of Emacs are very rigid. Try making a mode that allows point to be
> off-screen while scrolling like it can be in most other editors.
>
> Bear in mind also that when gedit was new, Emacs didn't have
> transient-mark-mode or shift-marking on by default and it didn't support
> bidirectional text. The Emacs configuration system is also completely
> different. Would you have integrated customize with gconf? How?
>

I am not sure what you are trying to say there, Daniel, but all these
points looks to me like things that could be (or are now) solved. (The
bidirectional text which Eli worked on was probably the hardest, of course.)

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

Re: Emacs terminology (not again!?)

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Sat, 18 Jan 2014 09:35:17 +0100
> Cc: Per Starbäck <per@starback.se>,
> 	"Richard M. Stallman" <rms@gnu.org>, David Kastrup <dak@gnu.org>,
> 	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > Bear in mind also that when gedit was new, Emacs didn't have
> > transient-mark-mode or shift-marking on by default and it didn't support
> > bidirectional text. The Emacs configuration system is also completely
> > different. Would you have integrated customize with gconf? How?
> >
> 
> I am not sure what you are trying to say there, Daniel, but all these
> points looks to me like things that could be (or are now) solved. (The
> bidirectional text which Eli worked on was probably the hardest, of course.)

Gedit's bidirectional editing support is woefully inadequate.  It's
not enough for an editor to link against Pango/Cairo/whatever that can
bidi-reorder a given string, to claim that it supports bidirectional
text.

Re: Emacs terminology (not again!?)

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

    Why was gedit developed? It looks advanced to me. (I have never used it.)
    Why was not Emacs used as a basis for gedit?

I don't know why gedit was developed, but I'd guess it was intended
to be 100% as simple as the editors of otherGUI systems.
-- 
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: Emacs terminology (not again!?) [was: Apologia for bzr]

[Eli Zaretskii]

> Date: Sat, 18 Jan 2014 00:13:50 +0100
> From: Per Starbäck <per@starback.se>
> Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Richard wrote:
> 
> > Emacs is never going to be as easy to learn as simple
> > editors, because ease of learning is not its priority.
> > The priority is effective editing for people willing to learn.
> > We won't sacrifice that goal for ease of learning.
> 
> I find this remark about "simple editors" interesting, not just in
> terms of Emacs, but of the whole GNU system. I have always thought
> of GNU Emacs as *the* editor in GNU, that is the default editor. Do
> you think a GNU system ideally instead should have some other
> ("simple") editor as the default editor?

That's not what Richard was saying, not at all.  There could very well
be a "simple" editor that is part of the GNU project (perhaps there is
one already).  No one said the GNU project must have only one editor.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 18 Jan 2014 00:13:50 +0100
> > From: Per Starbäck <per@starback.se>
> > Cc: David Kastrup <dak@gnu.org>, "emacs-devel@gnu.org" <
> emacs-devel@gnu.org>
> >
> > Richard wrote:
> >
> > > Emacs is never going to be as easy to learn as simple
> > > editors, because ease of learning is not its priority.
> > > The priority is effective editing for people willing to learn.
> > > We won't sacrifice that goal for ease of learning.
> >
> > I find this remark about "simple editors" interesting, not just in
> > terms of Emacs, but of the whole GNU system. I have always thought
> > of GNU Emacs as *the* editor in GNU, that is the default editor. Do
> > you think a GNU system ideally instead should have some other
> > ("simple") editor as the default editor?
>
> That's not what Richard was saying, not at all.  There could very well
> be a "simple" editor that is part of the GNU project (perhaps there is
> one already).  No one said the GNU project must have only one editor.
>
>
>
But this is of course not really true:

> > Emacs is never going to be as easy to learn as simple
> > editors, because ease of learning is not its priority.

There could be a setup of Emacs that is as easy as any editor to learn. It
is the advanced features that will take time to learn.

I guess that we are really discussing is if there is an advantage of such a
setup. In the light of that there was a whole new editor (gedit) created I
think there could have been a better route. Emacs could probably have
provided everything that gedit gives.

I also guess it would have been less work. And there would have been a
larger community using and working on Emacs.

This does not mean, I think, that the creating of gedit was a bad thing.
There are of course things on the positive side too. Those that created
gedit might speak better about that.

I believe the way forward is being open minded about plus and minus. In the
history and future. Everybody here has the capacity to be that. That is
what lead us to use Emacs, isn't it? ;-)

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

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

> On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Emacs is never going to be as easy to learn as simple
>> > editors, because ease of learning is not its priority.
>
> There could be a setup of Emacs that is as easy as any editor to
> learn.

That's a red herring.  What people are looking for are not editors that
are easy to learn, but editors that can be used without learning
anything at all.

I encounter this situation as an accordion player: the joke in
<URL:http://eu.art.com/products/p24328669009-sa-i7924441/uli-stein-akkordeon-kleiner.htm>,
namely somebody asking for a smaller-size accordion, is not without a
serious background: people imagine that capsizing a piano will make for
a good user interface.  It doesn't.  Back problems are frequent with
accordion players, and particularly women are often slumped in their
chairs in order to accommodate the vertical dimension of their keyboard.
I play a chromatic button accordion which has buttons rather than piano
keys, and I have 62 notes accessible where a piano accordion has at most
45, and even a small piano accordion with 37 keys has a larger height
than my instrument and its key mechanics take from the immediate
airflow/valve/button interaction facilitating good leggiero play and
bellows control.

If you take a look at nations where accordions are "mainstream" music
instruments, like Finland, France, Russia, you'll find a prevalence of
button instruments.  Internationally, it's about evenly split for
accordion soloists, and about 90% piano accordion for accordion
orchestra players (accordion orchestras are collection of accordionists
no other instrumentalists want to play with).  The ratio would be even
higher except for orchestras from those accordion nations where piano
accordions are considered outlandish altogether.

If viewed in the grand overall scheme of things, it begs the question if
we are doing Emacs a favor by giving it the piano keyboard more people
think they know how to work with.

Yes, it makes it easier to employ Emacs as a throwaway editor you
occasionally use and forget again.

> I guess that we are really discussing is if there is an advantage of
> such a setup. In the light of that there was a whole new editor
> (gedit) created I think there could have been a better route. Emacs
> could probably have provided everything that gedit gives.
>
> I also guess it would have been less work. And there would have been a
> larger community using and working on Emacs.

In countries where the piano accordion is prevalent, accordions are more
often associated with music styles, groups, and shows that "serious"
musicians consider a laughing stock.  That definitely impacts the influx
of new players.  And in particular, new virtuosi.

The future of Emacs depends on people with an attention span and
perseverence sufficient for extending it.  Those are the people who are
most likely to be annoyed at the inconsistency of concepts and
operations of things like the full CUA mode (the one which uses
heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
sense).

We should not try to be too clever about looking simple: we will only
fool those people who don't actually count towards the well-being of
Emacs.  So any changes should be done while keeping the coherence of the
result closely in check.

-- 
David Kastrup

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:

> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> > On Sat, Jan 18, 2014 at 9:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> > Emacs is never going to be as easy to learn as simple
> >> > editors, because ease of learning is not its priority.
> >
> > There could be a setup of Emacs that is as easy as any editor to
> > learn.
>
> That's a red herring.  What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.
>

Do you believe you will convince me with this, or? ;-)
Facts are much better if we do not agree. If we agreed this might have been
better, more fun, of course... ;-)


>
>
 > I guess that we are really discussing is if there is an advantage of
> > such a setup. In the light of that there was a whole new editor
> > (gedit) created I think there could have been a better route. Emacs
> > could probably have provided everything that gedit gives.
> >
> > I also guess it would have been less work. And there would have been a
> > larger community using and working on Emacs.
>
> The future of Emacs depends on people with an attention span and
> perseverence sufficient for extending it.  Those are the people who are
> most likely to be annoyed at the inconsistency of concepts and
> operations of things like the full CUA mode (the one which uses
> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
> sense).
>
> Are you really sure you want to look down upon those that do not agree? ;-)

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

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

> On Sat, Jan 18, 2014 at 11:02 AM, David Kastrup <dak@gnu.org> wrote:
>
>> Lennart Borgman <lennart.borgman@gmail.com> writes:

>> > I guess that we are really discussing is if there is an advantage of
>> > such a setup. In the light of that there was a whole new editor
>> > (gedit) created I think there could have been a better route. Emacs
>> > could probably have provided everything that gedit gives.
>> >
>> > I also guess it would have been less work. And there would have been a
>> > larger community using and working on Emacs.
>>
>> The future of Emacs depends on people with an attention span and
>> perseverence sufficient for extending it.  Those are the people who are
>> most likely to be annoyed at the inconsistency of concepts and
>> operations of things like the full CUA mode (the one which uses
>> heuristics to decide whether to use C-x and C-c in the Emacs or the CUA
>> sense).
>
> Are you really sure you want to look down upon those that do not
> agree? ;-)

It's not a question on looking up or down.  Let me quote from the CUA
mode section in the Emacs manual:

    The command ‘M-x cua-mode’ sets up key bindings that are compatible with
    the Common User Access (CUA) system used in many other applications.

       When CUA mode is enabled, the keys ‘C-x’, ‘C-c’, ‘C-v’, and ‘C-z’
    invoke commands that cut (kill), copy, paste (yank), and undo
    respectively.  The ‘C-x’ and ‘C-c’ keys perform cut and copy only if the
    region is active.  Otherwise, they still act as prefix keys, so that
    standard Emacs commands like ‘C-x C-c’ still work.  Note that this means
    the variable ‘mark-even-if-inactive’ has no effect for ‘C-x’ and ‘C-c’
    (*note Using Region::).

       To enter an Emacs command like ‘C-x C-f’ while the mark is active,
    use one of the following methods: either hold ‘Shift’ together with the
    prefix key, e.g., ‘S-C-x C-f’, or quickly type the prefix key twice,
    e.g., ‘C-x C-x C-f’.

Now this is touted as a feature to make things _simple_ for people.  In
reality, _competent_ use of it requires _lots_ of learning and
surprises.  If I enable CUA mode and type C-h k C-x C-c, I read

    C-x C-c runs the command save-buffers-kill-terminal, which is an
    interactive compiled Lisp function in `files.el'.

    It is bound to C-x C-c, <menu-bar> <file> <exit-emacs>.

    (save-buffers-kill-terminal &optional ARG)

    Offer to save each buffer, then kill the current connection.
    If the current frame has no client, kill Emacs itself.

    With prefix ARG, silently save all file-visiting buffers, then kill.

    If emacsclient was started with a list of filenames to edit, then
    only these files will be asked to be saved.

    [back]

But if there is an active region, C-h k C-x prints

    C-x runs the command cua--prefix-override-handler, which is an
    interactive compiled Lisp function in `cua-base.el'.

    It is bound to C-c, C-x.

    (cua--prefix-override-handler ARG)

    Start timer waiting for prefix key to be followed by another key.
    Repeating prefix key when region is active works as a single prefix key.

    [back]

This kind of mode dependency is what Emacs proponents in the editor wars
tend to describe as a disadvantage of vi.

This kind of "do the expected thing" setup may delay the time until
cursory Emacs users will hit a wall of learning.  But when they do, the
wall is higher.

This puts a larger complexity gap between "simple users" and "power
users or programmers" who actually can work their tool with confidence.

I don't see that making Emacs fit the Gedit task space would have
yielded a result where Gedmacs users would have grown into active
participants of the Emacs universe.

In the long run, we need to make sure that Emacs remains comprehensible
to Emacs users.  That does not preclude changing keybindings and
concepts, but getting multiple concurrent warring keybindings and
concepts sorted by various heuristics is not the way to simplicity.

-- 
David Kastrup

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Sivaram Neelakantan]

On Sat, Jan 18 2014,David Kastrup wrote:

[snipped 92 lines]

> In the long run, we need to make sure that Emacs remains comprehensible
> to Emacs users.  That does not preclude changing keybindings and
> concepts, but getting multiple concurrent warring keybindings and
> concepts sorted by various heuristics is not the way to simplicity.

No offence to the CUA/EVIL developers but don't these 2 modes get in
the way of Emacs mastery as David says.  I can understand someone
asking for the vi . (dot command) functionality equivalent in Emacs
but why humour them with modes that are at cross purposes to Emacs
proficiency?  

Here, simplicity begets simple users(with no offence to their
intelligence, just Emacs mastery)

 sivaram
 -- 

Re: Emacs terminology (not again!?)

[Óscar Fuentes]

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

> No offence to the CUA/EVIL developers but don't these 2 modes get in
> the way of Emacs mastery as David says.  I can understand someone
> asking for the vi . (dot command) functionality equivalent in Emacs
> but why humour them with modes that are at cross purposes to Emacs
> proficiency?  

After 12+ years of kosher Emacs use, some months ago I started to use
Evil and my editing proficiency (not to mention my RSSI) improved
noticeably.

We all agree that not everything that Emacs does is the best for
everybody. I'll go further and say that some Emacs things are quite bad.
Default keybindings, for instance.

[snip]

Re: Emacs terminology (not again!?)

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Sivaram Neelakantan <nsivaram.net@gmail.com> writes:
>
>> No offence to the CUA/EVIL developers but don't these 2 modes get in
>> the way of Emacs mastery as David says.  I can understand someone
>> asking for the vi . (dot command) functionality equivalent in Emacs
>> but why humour them with modes that are at cross purposes to Emacs
>> proficiency?  
>
> After 12+ years of kosher Emacs use, some months ago I started to use
> Evil and my editing proficiency (not to mention my RSSI) improved
> noticeably.
>
> We all agree that not everything that Emacs does is the best for
> everybody. I'll go further and say that some Emacs things are quite
> bad.  Default keybindings, for instance.

Regarding cursor movements, I tend to agree.  I'm using the cursor block
instead here: it's not as well located as on my first computer, a
Nascom II where it it's in home-position reach, but one can get used to
working with it.

Emacs improves when telling your keyboard that it should employ the
CapsLock key (who needs that?) as Control.  I've not used viper mode
myself: I think it has fewer conflicts with the standard Emacs
keybindings than CUA-mode has.  Of course, it still makes your Emacs
diverge from the Emacs explained in the manuals, so in that respect
alone, it is not a learner's environment.

-- 
David Kastrup

Re: Emacs terminology (not again!?)

[Sven Axelsson]

As a new Emacs user (well, I have tried several times before
but always given up after a while), I'd really like to ask this:

Cursor movement - I see in the documentation and all over the
Internet stated that you should use the default movement
shortcuts because they are much more efficient than the arrow
key bindings. Do people really find this true? OK, They are
somewhat mnemonic, but efficient? Especially on keyboards
missing a right Ctrl key I find them pretty awkward.

Maybe I should try EVIL and see if that makes me more efficient.

-- 
Sven Axelsson
++++++++++[>++++++++++>+++++++++++>++++++++++>++++++
>++++<<<<<-]>++++.+.++++.>+++++.>+.<<-.>>+.>++++.<<.
+++.>-.<<++.>>----.<++.>>>++++++.<<<<.>>++++.<----.

Re: Emacs terminology (not again!?)

[Tom]

Sven Axelsson <sven.axelsson <at> gmail.com> writes:
> 
> Cursor movement - I see in the documentation and all over the
> Internet stated that you should use the default movement
> shortcuts because they are much more efficient than the arrow
> key bindings. Do people really find this true? 

I'm a longtime emacs users (>15 years) and I don't use those
keys. I use the arrow keys. Use what you find comfortable.

As far as I'm concerned most of the default bindings are
uncomfortable (C-f, C-n, C-n, C-p etc.) and I don't use them.

Create your own Emacs experience. The great thing with emacs is
that you can do that. There is no single optimal way which fits
everybody.

Re: Emacs terminology (not again!?)

[chad]

On 18 Jan 2014, at 13:55, Sven Axelsson <sven.axelsson@gmail.com> wrote:

> Cursor movement - I see in the documentation and all over the
> Internet stated that you should use the default movement
> shortcuts because they are much more efficient than the arrow
> key bindings. Do people really find this true? OK, They are
> somewhat mnemonic, but efficient? Especially on keyboards
> missing a right Ctrl key I find them pretty awkward.
> 
> Maybe I should try EVIL and see if that makes me more efficient.

Its not so much about using n, p, f, and b as it is about keeping
your hands in position above the home row. This is also why so many
emacs users make Caps_Lock into a control key - easy access from
the home row.

The RSI angle is similar - moving your hand from the home row
position to the arrow key cluster position _quickly_ often involves
twisting ones wrist in a way that can exacerbate RSI problems. When
youre primarily navigating around a buffer, you probably move your
arm so that yours fingers rest naturally above the arrow keys, but
if youre doing a lot of mixed typing and navigation, then youre
more likely to be twisting your wrist to keep your hand nearer to
that home row position (I think this is adduction/abduction, but
my physiology classes were a long time ago).

Early on, emacs users were especially likely to be using big
battleship keyboards, with arrow key clusters so far away that
moving the arm was required (lowering efficiency) or requiring a
more severe twist to the wrist. I believe this is where the efficiency
argument comes from, but thats just a theory.

Hope that helps,
~Chad

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Tom]

Sivaram Neelakantan <nsivaram.net <at> gmail.com> writes:
> 
> No offence to the CUA/EVIL developers but don't these 2 modes get in
> the way of Emacs mastery as David says.  I can understand someone
> asking for the vi . (dot command) functionality equivalent in Emacs
> but why humour them with modes that are at cross purposes to Emacs
> proficiency?  

Emacs mastery is not about using the default keys, it's about 
understanding how you can transform Emacs, so it adapts to you,
not the other way around.

I often read from beginners in forums that they think the
keybindings give emacs its power, though the real power is
the lisp environment which allows you to create your own
personal working environment including completely revamping
them and using vi bindings if you want.

So Emacs proficiency has nothing to do with the keys. They
are only the legacy defaults which can be changed as any other
custom aspects of emacs.

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Óscar Fuentes]

David Kastrup <dak@gnu.org> writes:

> That's a red herring.  What people are looking for are not editors that
> are easy to learn, but editors that can be used without learning
> anything at all.

People are looking for editors that work similar enough to those that
they already know.

For most people, the *promise* of improved efficiency is not credible
enough to invest the required time to learn Emacs.

[snip]

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[David Kastrup]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> That's a red herring.  What people are looking for are not editors that
>> are easy to learn, but editors that can be used without learning
>> anything at all.
>
> People are looking for editors that work similar enough to those that
> they already know.
>
> For most people, the *promise* of improved efficiency is not credible
> enough to invest the required time to learn Emacs.

I'm not convinced that this should overly influence our priorities.
It's like trying to make a piano appealing to iPod users.  Both are used
for producing music.

What _should_ be making us think about our priorities is when we lose
the input of heavy Emacs users like RMS, Ben Wing, Nix, to Repetitive
Strain Injury, and it appears like users of other editors are not
affected to a similar degree.

No idea about the actual numbers, though.  If they turned out to be more
than just anecdotal, that would at least provide an incentive for
long-term replanning of the default keybindings to be offered.

To me, that would carry more weight than "everybody else does x".

-- 
David Kastrup

Re: Emacs terminology (not again!?)

[Stephen J. Turnbull]

David Kastrup writes:

 > What _should_ be making us think about our priorities is when we lose
 > the input of heavy Emacs users like RMS, Ben Wing, Nix, to Repetitive
 > Strain Injury, and it appears like users of other editors are not
 > affected to a similar degree.

Ben wasn't RSI (the disease affected all of his joints) although the
end effect was very similar.  As for those three examples, I suspect
the controlling factor is that they can write code faster than even
Emacs can help them type it.  I haven't met the other two, but I've
watched Ben work, and his runs of non-stop typing run to minutes, as
if he was a court stenographer trying to keep up with the Devil and
Daniel Webster.[1]

But I think the important point is the one that Lennart made: Emacs's
editing primitives and editor construction language are the important
thing, and the default keymaps are just a way for the community to
standardize things like tutorials and organize new addition to the set
of key-bound commands.  It's a shame that there isn't a powerful
facility for theming keymaps.

Footnotes: 
[1]  American folklore -- Daniel Webster was a lawyer who argued Satan
to a standstill when he came to collect on a sold soul deal.  It took
a while. :-)

Re: Emacs terminology (not again!?)

[Xue Fuqiao]

On Sun, Jan 19, 2014 at 8:59 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> But I think the important point is the one that Lennart made: Emacs's
> editing primitives and editor construction language are the important
> thing, and the default keymaps are just a way for the community to
> standardize things like tutorials and organize new addition to the set
> of key-bound commands.  It's a shame that there isn't a powerful
> facility for theming keymaps.

+1

FWIW ergoemacs-mode can let you theme keymaps:

https://github.com/ergoemacs/ergoemacs-mode

-- 
http://www.gnu.org/software/emacs/

Re: Emacs terminology (not again!?) [was: 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. ]]]

    There could be a setup of Emacs that is as easy as any editor to learn. It
    is the advanced features that will take time to learn.

    I guess that we are really discussing is if there is an advantage of such a
    setup.

We could make an incompatible "simple" interface for Emacs and make it
easy to learn.  It could look just like gedit, perhaps.

It might be better, overall, if gedit were implemented as such an
interface to Emacs.  I am not sure it would have been less work, though.

However, if you change it that much, it won't give people an easy pathway
to using Emacs.  Its commands would be all different.



-- 
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: Emacs terminology (not again!?) [was: Apologia for bzr]

[Lennart Borgman]

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

On Sun, Jan 19, 2014 at 1:10 PM, Richard Stallman <rms@gnu.org> wrote:

>
> We could make an incompatible "simple" interface for Emacs and make it
> easy to learn.  It could look just like gedit, perhaps.
>
> It might be better, overall, if gedit were implemented as such an
> interface to Emacs.  I am not sure it would have been less work, though.
>

Perhaps it does not matter if it would have been less work in the
beginning. Perhaps the long term outcome matters more.


>
> However, if you change it that much, it won't give people an easy pathway
> to using Emacs.  Its commands would be all different.
>
> I see no reason the commands would be different. Not at the beginners
level.

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

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Phillip Lord]

Lennart Borgman <lennart.borgman@gmail.com> writes:
>> > Emacs is never going to be as easy to learn as simple
>> > editors, because ease of learning is not its priority.
>
> There could be a setup of Emacs that is as easy as any editor to learn. It
> is the advanced features that will take time to learn.

For what it is worth, I think Emacs could do with some considerable
improvement on the "self-documenting" front. A student of mine recently
asked about tutorials for Emacs. Of course, I said, it's got one
built-in, to which the response was that it was rubbish.

So I went and looked at it for the first time in many years. I think he
has a point. As the warning notice that you get if you change things says:

"The main purpose of the Emacs tutorial is to teach you
the most important standard Emacs commands (key bindings)."

Are key bindings the main thing we want to teach new users?

Worse the first 200 lines are all about how to move the cursor; I mean,
most new users are just going to use the cursor keys, or a mouse. It's
what I do, even after years of using Emacs with a few exceptions
(Ctrl-A, E and M-<,> if you are interested).

It isn't till line 199 that you get something powerful (repeat commands)
rather than painful. Then, we move onto Ctrl-G (line 236) which is what
happens when it breaks. And line 274 get us to Windows. And line 470
before we find out how to open a file.

There are also 4 "If you are on a windowing system" statements: lets be
honest, any new user is going to be on a windowing system. People
starting to use computers today are likely to be unaware that it is
possible to not be on a windowing system.

Other things that seem to be missing, are links to the rest of the
world. Why no links to web pages, or videos? Or indeed, in-line images.

Perhaps, users would be less confused by "windows", "buffers" and so on,
if they hadn't got bored long before the point where these are
explained?

If there is interest in incorporating it, I'd be willing to rewrite it.

Phil

New tutorial (was: Emacs terminology (not again!?) [was: Apologia for bzr])

[Stefan Monnier]

> Other things that seem to be missing, are links to the rest of the
> world.  Why no links to web pages, or videos? Or indeed, in-line images.

There aren't many web pages worthy of being linked to, but yes, the few
out there should be shown.

> If there is interest in incorporating it, I'd be willing to rewrite it.

I'd welcome a new tutorial, that takes the same idea as the original one
(i.e. a kind of "participative reading") but focuses on more powerful
features such as keyboard macros, sexp-based movement.  Of course, it
should still include explanations about the C-foo notation, the concept
of buffers and windows, etc... Advertising things like Org mode would
also make a lot of sense.

If it could be visually more appealing, it would be a plus.


        Stefan

Re: Emacs terminology (not again!?) [was: Apologia for bzr]

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Date: Mon, 20 Jan 2014 12:22:45 +0000
> 
> For what it is worth, I think Emacs could do with some considerable
> improvement on the "self-documenting" front. A student of mine recently
> asked about tutorials for Emacs. Of course, I said, it's got one
> built-in, to which the response was that it was rubbish.
> 
> So I went and looked at it for the first time in many years. I think he
> has a point.

Indeed.  Volunteers are welcome to work on this.

> Worse the first 200 lines are all about how to move the cursor;

But let's be fair: the tutorial starts by saying that arrow keys and
PgUp/PgDn are also supported.

> If there is interest in incorporating it, I'd be willing to rewrite it.

Please do, and thanks in advance.

Re: Emacs terminology (not again!?)

[Glenn Morris]

Phillip Lord wrote:

> Other things that seem to be missing, are links to the rest of the
> world. Why no links to web pages, or videos? Or indeed, in-line images.

You may prefer http://www.gnu.org/software/emacs/tour/

Yes, the built-in tutorial is old. Updating it (and its translations) is
a big task that no-one has had the energy for.

Re: Emacs terminology (not again!?)

[Stefan Monnier]

> Yes, the built-in tutorial is old.  Updating it (and its translations) is
> a big task that no-one has had the energy for.

It's not necessary for all translations to be updated at the same time.


        Stefan

New tutorial (was: Emacs terminology (not again!?) [was: Apologia for bzr])

[Phillip Lord]

>> If there is interest in incorporating it, I'd be willing to rewrite it.

> I'd welcome a new tutorial, that takes the same idea as the original
> one (i.e. a kind of "participative reading") but focuses on more
> powerful features such as keyboard macros, sexp-based movement. Of
> course, it should still include explanations about the C-foo notation,
> the concept of buffers and windows, etc... 

This was my idea. There is nothing wrong with talking about keyboard
controlled motion, but there is too much of it, and it should not be at
the start.

> Advertising things like Org mode would also make a lot of sense.

I think more "where to go from here" stuff would be an important
addition. Actually, I was thinking of writing it using org, then
exporting to text (minus markup).

> If it could be visually more appealing, it would be a plus.

Again, I agree, while noting that "visually appealing" is not one of my
big skills in life.

I'll have a think about it, and post here when I have more news. I'll
probably set up a repo somewhere to get going. Anyone got any options
about which VCS I should use?

Phil

(last sentence was an attempt at humour)

Re: Emacs terminology (not again!?)

[Phillip Lord]

Glenn Morris <rgm@gnu.org> writes:

> Phillip Lord wrote:
>
>> Other things that seem to be missing, are links to the rest of the
>> world. Why no links to web pages, or videos? Or indeed, in-line images.
>
> You may prefer http://www.gnu.org/software/emacs/tour/
>
> Yes, the built-in tutorial is old. Updating it (and its translations) is
> a big task that no-one has had the energy for.

Maybe it is. I was offering to do so.

Phil

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

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

[Bozhidar Batsov]

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

On 2 January 2014 19:56, Eli Zaretskii <eliz@gnu.org> wrote:

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


Try running bzr with Python 3 for instance... Probably this is never going
to happen. I took quite some time for
bzr to become compatible with Python 2.7. Git works pretty well on Windows
these days, but admitted this was not the situation
few years ago.


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


Is this so? Many things in bzr seem like black magic to me. Such assertions
are extremely subjective, of course.


> 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 the git man pages are pretty decent and the online docs are superb.


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

I have the same problem using bzr - as everything is different from git in
subtle and not
so subtle ways.


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

bzr has some pretty serious weaknesses - its conflict resolution mechanism
is terrible for instance.
On the Emacs side of things - git users can benefit from the power of magit
and with bzr we have only vc-dir to work with.
I think this is a tide not worth fighting. I had some problems years ago
migrating from SVN (and the associated mindset) to
git, but once I grokked git I've never looked back.

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

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

[Eli Zaretskii]

> Date: Thu, 2 Jan 2014 20:40:40 +0200
> From: Bozhidar Batsov <bozhidar@batsov.com>
> Cc: Eric Raymond <esr@thyrsus.com>, Karl Fogel <kfogel@red-bean.com>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Try running bzr with Python 3 for instance... Probably this is never going
> to happen. I took quite some time for
> bzr to become compatible with Python 2.7.

Why should I care what version of Python is used under the hood?
(Mine is 2.6.6, btw.)

> Git works pretty well on Windows these days

Pretty well my foot: it requires a complete separate shell set up with
a separate PATH, to keep its singular version of MSYS out of my main
development environment.

> bzr has some pretty serious weaknesses - its conflict resolution mechanism
> is terrible for instance.

There's a single command to learn, and once you done that, you will
never have any problems with conflicts.

> On the Emacs side of things - git users can benefit from the power of magit
> and with bzr we have only vc-dir to work with.
> I think this is a tide not worth fighting. I had some problems years ago
> migrating from SVN (and the associated mindset) to
> git, but once I grokked git I've never looked back.

Didn't I tell that I do use git?

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Git works pretty well on Windows these days
>
> Pretty well my foot: it requires a complete separate shell set up with
> a separate PATH, to keep its singular version of MSYS out of my main
> development environment.

This is not correct. You only need git.cmd in the PATH and, IIRC, that
is avoidable too if you use git from Emacs interfaces (VC and/or Magit).

As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
MSYS.dll (it is a "native" Windows executable.) It would be interesting
to know which functionality is missing if you remove the stuff that
depends on MSYS.dll from MSYSGit package.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 02 Jan 2014 22:22:17 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Git works pretty well on Windows these days
> >
> > Pretty well my foot: it requires a complete separate shell set up with
> > a separate PATH, to keep its singular version of MSYS out of my main
> > development environment.
> 
> This is not correct. You only need git.cmd in the PATH and, IIRC, that
> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).

That is only a solution if you don't use git from the command line.

> As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
> MSYS.dll

No, but some git commands need Bash and shell scripts, and thus invoke
MSYS programs that do need the MSYS DLL.

> It would be interesting to know which functionality is missing if
> you remove the stuff that depends on MSYS.dll from MSYSGit package.

If someone knows where to find this information, please speak up.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> This is not correct. You only need git.cmd in the PATH and, IIRC, that
>> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).
>
> That is only a solution if you don't use git from the command line.

git.cmd can be used from the command line. BTW, on my latest install
there is no git.cmd, but a single git.exe executable in Git\cmd
directory.

>> As a curiosity, I'll mention that MSYSGit git.exe doesn't depend on
>> MSYS.dll
>
> No, but some git commands need Bash and shell scripts, and thus invoke
> MSYS programs that do need the MSYS DLL.

You don't need MSYS on the PATH, so whatever those commands use is an
interal implementation detail.

[snip]

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 15:53:01 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This is not correct. You only need git.cmd in the PATH and, IIRC, that
> >> is avoidable too if you use git from Emacs interfaces (VC and/or Magit).
> >
> > That is only a solution if you don't use git from the command line.
> 
> git.cmd can be used from the command line.

Did you actually try that, for real?  git.cmd sets PATH to include
git's binaries, which include MSYS DLL.  This means you cannot use in
the same session any commands that might conflict.  E.g., consider
what would happen if you invoke git.cmd from a Makefile, or the other
way around.  I tried that, and got stuck and crashing programs.  No,
thanks.

> > No, but some git commands need Bash and shell scripts, and thus invoke
> > MSYS programs that do need the MSYS DLL.
> 
> You don't need MSYS on the PATH, so whatever those commands use is an
> interal implementation detail.

No, it isn't.  When MSYS DLL is loaded, any other program that is
linked to that DLL will try to use it -- and will fail if it needs an
incompatible version of that DLL.  Therefore, you can't invoke, say,
the MSYS 'make' from the Git Bash shell, or from any Git command.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> git.cmd can be used from the command line.
>
> Did you actually try that, for real?  git.cmd sets PATH to include
> git's binaries, which include MSYS DLL.  This means you cannot use in
> the same session any commands that might conflict.  E.g., consider
> what would happen if you invoke git.cmd from a Makefile, or the other
> way around.  I tried that, and got stuck and crashing programs.  No,
> thanks.

git.cmd is not meant to permanently set any variable. It is invoked from
a shell as

`git <args>'

Whatever environment variables it sets are effective only until the
command finishes, and for that sole command.

As previously mentioned, there is no git.cmd anymore but a git.exe that
knows where the other commands are located.

>> > No, but some git commands need Bash and shell scripts, and thus invoke
>> > MSYS programs that do need the MSYS DLL.
>> 
>> You don't need MSYS on the PATH, so whatever those commands use is an
>> interal implementation detail.
>
> No, it isn't.  When MSYS DLL is loaded, any other program that is
> linked to that DLL will try to use it -- and will fail if it needs an
> incompatible version of that DLL.  Therefore, you can't invoke, say,
> the MSYS 'make' from the Git Bash shell, or from any Git command.

Are you sure about this? Windows allows multiple DLLs with the same
names and every application will load one of them as per the effective
environment when the application is launched. So if you don't put
MSYSGit binary directory on the PATH, its existence shouldn't make a
difference for the rest of the system. A different history is if you
invoke an MSYS (or Cygwin) executable from MSYSGit, or vice-versa, but
that is an improbable scenario (please keep in mind that git.exe is not
a MSYS binary, so invoking it from Cygwin/MSYS shouldn't be problematic,
at least for the usual git commands.)

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 16:32:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> git.cmd can be used from the command line.
> >
> > Did you actually try that, for real?  git.cmd sets PATH to include
> > git's binaries, which include MSYS DLL.  This means you cannot use in
> > the same session any commands that might conflict.  E.g., consider
> > what would happen if you invoke git.cmd from a Makefile, or the other
> > way around.  I tried that, and got stuck and crashing programs.  No,
> > thanks.
> 
> git.cmd is not meant to permanently set any variable. It is invoked from
> a shell as
> 
> `git <args>'
> 
> Whatever environment variables it sets are effective only until the
> command finishes, and for that sole command.

Yes, and what happens if that command then invokes something that is
not in the git's bin directory?

> As previously mentioned, there is no git.cmd anymore but a git.exe that
> knows where the other commands are located.

I still have git.cmd after installing the latest msysgit, FWIW.  Not
that I'm using it.

> >> > No, but some git commands need Bash and shell scripts, and thus invoke
> >> > MSYS programs that do need the MSYS DLL.
> >> 
> >> You don't need MSYS on the PATH, so whatever those commands use is an
> >> interal implementation detail.
> >
> > No, it isn't.  When MSYS DLL is loaded, any other program that is
> > linked to that DLL will try to use it -- and will fail if it needs an
> > incompatible version of that DLL.  Therefore, you can't invoke, say,
> > the MSYS 'make' from the Git Bash shell, or from any Git command.
> 
> Are you sure about this? Windows allows multiple DLLs with the same
> names and every application will load one of them as per the effective
> environment when the application is launched.

Not if they have the same name.  An application that was linked
against FOO.DLL will ask the OS to load the first FOO.DLL on the DLL
search path.  If a DLL with the same base name is already in memory,
Windows doesn't look for it, it just uses what's already in memory.
See this page for the details:

  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

You _can_ have different DLLs with the same functionality, but they
must have different names, as in libpng13.dll and libpng16.dll, and
each executable should specify the name it wants in its import table.

When you install both msysgit and MSYS that uses a different MSYS DLL,
you have a small DLL hell on your hands.  That's why I keep them
separate: to avoid that.

> A different history is if you invoke an MSYS (or Cygwin) executable
> from MSYSGit, or vice-versa, but that is an improbable scenario
> (please keep in mind that git.exe is not a MSYS binary, so invoking
> it from Cygwin/MSYS shouldn't be problematic, at least for the usual
> git commands.)

Well, I run git from Bash, so an MSYS binary is already in the air
when I invoke any git commands.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Whatever environment variables it sets are effective only until the
>> command finishes, and for that sole command.
>
> Yes, and what happens if that command then invokes something that is
> not in the git's bin directory?

How could that happen? MSYSGit is self-contained. You can set some git
configuration params for using external diff tools, for instance, but
then you should make sure that those tools are compatible with MSYSGit
(which means, essentially, that no Cygwin or MSYS binaries allowed.)

>> As previously mentioned, there is no git.cmd anymore but a git.exe that
>> knows where the other commands are located.
>
> I still have git.cmd after installing the latest msysgit, FWIW.  Not
> that I'm using it.

I'm using MSYSGit 1.8.4.msysgit.0 and int Git/cmd there is git.exe and
gitk.cmd. There is no git.cmd anywhere. Maybe they reverted that change.

>> Are you sure about this? Windows allows multiple DLLs with the same
>> names and every application will load one of them as per the effective
>> environment when the application is launched.
>
> Not if they have the same name.  An application that was linked
> against FOO.DLL will ask the OS to load the first FOO.DLL on the DLL
> search path.  If a DLL with the same base name is already in memory,
> Windows doesn't look for it, it just uses what's already in memory.
> See this page for the details:
>
>   http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Those rules affects a given process. That means that the fact that
process `foo' loaded certain DLLs does not affect which DLLs are loaded
for process `bar', even when `bar' is executed from `foo'.

For Cygwin and MSYS processes the incompatibility doesn't come from the
DLL loading system (assuming that each executable loads the correct DLL,
as it should because they live on the same directory) but from
collisions on objects that are used or created by Cygwin/MSYS.

[snip]

> Well, I run git from Bash, so an MSYS binary is already in the air
> when I invoke any git commands.

It would be quick enough to run some common git commands from MSYS shell
to see if it works: clone, pull, status, log...

BTW, there is MSYS2 [1], that comes with lots of packages (managed with
pacman, an awesome package manager) including git. I built Emacs from
MSYS2 a few days ago and it worked (just a small compile issue related
to MinGW-w64.) MSYSGit is quite faster than MSYS2 git, though.

[1] https://sourceforge.net/projects/msys2/

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 17:28:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Whatever environment variables it sets are effective only until the
> >> command finishes, and for that sole command.
> >
> > Yes, and what happens if that command then invokes something that is
> > not in the git's bin directory?
> 
> How could that happen?

You wanna bet?  I prefer an environment where I know what can and what
cannot happen.

> Those rules affects a given process. That means that the fact that
> process `foo' loaded certain DLLs does not affect which DLLs are loaded
> for process `bar', even when `bar' is executed from `foo'.

I invoked 'make' from the Bash that was installed by msysgit.  That
'make' hang.  The same command runs just fine from the MSYS Bash I use
for configuring and building packages.  That's a fact.  I think I know
the reasons, but if you want to disagree and live dangerously, that's
fine by me.

> It would be quick enough to run some common git commands from MSYS shell
> to see if it works: clone, pull, status, log...

I already tried, see above.

> BTW, there is MSYS2 [1], that comes with lots of packages (managed with
> pacman, an awesome package manager) including git. I built Emacs from
> MSYS2 a few days ago and it worked (just a small compile issue related
> to MinGW-w64.) MSYSGit is quite faster than MSYS2 git, though.

Thanks, I know about MSYS2.  My current MSYS environment is well tuned
and satisfies me, so I feel no need to switch.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> You wanna bet?  I prefer an environment where I know what can and what
> cannot happen.

So yo do worry about hypothetical, unknown problems (unknown unknowns).
That's fine, but hardly a serious argument against MSYSGit.

>> Those rules affects a given process. That means that the fact that
>> process `foo' loaded certain DLLs does not affect which DLLs are loaded
>> for process `bar', even when `bar' is executed from `foo'.
>
> I invoked 'make' from the Bash that was installed by msysgit.  That
> 'make' hang.  The same command runs just fine from the MSYS Bash I use
> for configuring and building packages.  That's a fact.  I think I know
> the reasons, but if you want to disagree and live dangerously, that's
> fine by me.

IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
times, that's not expected to work.

>> It would be quick enough to run some common git commands from MSYS shell
>> to see if it works: clone, pull, status, log...
>
> I already tried, see above.

No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
git.exe from a MSYS terminal worked fine for the commands I mentioned
above.

[snip]

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 21:37:08 +0100
> 
> > I invoked 'make' from the Bash that was installed by msysgit.  That
> > 'make' hang.  The same command runs just fine from the MSYS Bash I use
> > for configuring and building packages.  That's a fact.  I think I know
> > the reasons, but if you want to disagree and live dangerously, that's
> > fine by me.
> 
> IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
> times, that's not expected to work.

Right, and that's why I keep the two segregated.  That was all I was
saying from day one: it's a PITA to have two similar, but incompatible
environments.  E.g., I cannot build a package from the same shell
where I "git pull" it.

> >> It would be quick enough to run some common git commands from MSYS shell
> >> to see if it works: clone, pull, status, log...
> >
> > I already tried, see above.
> 
> No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
> experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
> git.exe from a MSYS terminal worked fine for the commands I mentioned
> above.

Until that git.exe invokes a sub-command that needs Bash or Perl, and
will then invoke its own Bash pr Perl that need an incompatible
msys.dll (and other DLLs, like libiconv).

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> IIUC you invoked MSYS `make' from MSYSGit `bash'. As I said multiple
>> times, that's not expected to work.
>
> Right, and that's why I keep the two segregated.  That was all I was
> saying from day one: it's a PITA to have two similar, but incompatible
> environments.  E.g., I cannot build a package from the same shell
> where I "git pull" it.

As already mentioned, you can `git pull' on a MSYS shell, so it is false
that you can't `make' on the same shell that you did the `pull'
operation.

>> No, you didn't. As git.exe does not depend on MSYS.dll, the problems you
>> experienced with `make' shouldn't happen. And, indeed, invoking MSYSGit
>> git.exe from a MSYS terminal worked fine for the commands I mentioned
>> above.
>
> Until that git.exe invokes a sub-command that needs Bash or Perl, and
> will then invoke its own Bash pr Perl that need an incompatible
> msys.dll (and other DLLs, like libiconv).

Curiously enough, `git pull' seems to be a Perl script (the executables
and scripts are on Git/libexec/git-core.) But it works from MSYS, hence
somehow the problem is not so serious.

I suggest that for the time being we stop worrying about what unkown
problems might be lurking and wait for something concrete to
materialize.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 03 Jan 2014 22:38:35 +0100
> 
> Curiously enough, `git pull' seems to be a Perl script (the executables
> and scripts are on Git/libexec/git-core.) But it works from MSYS, hence
> somehow the problem is not so serious.

For you, maybe, and with the current versions of the MSYS DLL that you
have in msysgit and in MSYS.  But relying on this is living
dangerously and _will_ some day require you to deal with strange
failures and crashes during a build.  No, thanks.  I've fought that
war once and decided that I never again want to go that way.

> I suggest that for the time being we stop worrying about what unkown
> problems might be lurking and wait for something concrete to
> materialize.

If you use MSYS and msysgit my way, you don't have to wait for
anything to materialize, because it won't.  It's just inconvenient, as
I need to have 2 separate shell sessions open at all times, and
remember to switch to the right one depending on what I want to do.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

> If you use MSYS and msysgit my way, you don't have to wait for
> anything to materialize, because it won't.  It's just inconvenient, as
> I need to have 2 separate shell sessions open at all times, and
> remember to switch to the right one depending on what I want to do.

Why do you need an MSYSGit shell open at all times? Have you tried any
of the Emacs interfaces for Git? (I highly recommend Magit, which is
*immensely* more convenient than the command line for everyday's work)

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 18:30:53 +0100
> 
> Why do you need an MSYSGit shell open at all times?

Because that's the only way to ensure everything in git will work as
best as it can.

> Have you tried any of the Emacs interfaces for Git? (I highly
> recommend Magit, which is *immensely* more convenient than the
> command line for everyday's work)

I don't trust any of these interfaces to work correctly with MSYS
based commands and scripts, sorry.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Why do you need an MSYSGit shell open at all times?
>
> Because that's the only way to ensure everything in git will work as
> best as it can.
>
>> Have you tried any of the Emacs interfaces for Git? (I highly
>> recommend Magit, which is *immensely* more convenient than the
>> command line for everyday's work)
>
> I don't trust any of these interfaces to work correctly with MSYS
> based commands and scripts, sorry.

So you are using an inconvenient setup because you are afraid of
hypothetical problems and refuse to switch to an alternative, convenient
setup because you are afraid of other, even more hypothetical problems?
:-)

I'm using MSYSGit + VC + Magit on Windows for several years and it never
caused a single data-loss issue. At the very beginning, long time ago, I
had problems with line-endings but then MSYSGit was "fixed".

OTOH I have a hack on my .emacs to prevent Emacs + Bzr from garbling the
commit messages. Something related to character encodings.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 21:19:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Why do you need an MSYSGit shell open at all times?
> >
> > Because that's the only way to ensure everything in git will work as
> > best as it can.
> >
> >> Have you tried any of the Emacs interfaces for Git? (I highly
> >> recommend Magit, which is *immensely* more convenient than the
> >> command line for everyday's work)
> >
> > I don't trust any of these interfaces to work correctly with MSYS
> > based commands and scripts, sorry.
> 
> So you are using an inconvenient setup because you are afraid of
> hypothetical problems and refuse to switch to an alternative, convenient
> setup because you are afraid of other, even more hypothetical problems?
> :-)

They are not hypothetical, believe me.  I have a lot gray hair to
vouch for that, and too little time to waste on this again.

> I'm using MSYSGit + VC + Magit on Windows for several years and it never
> caused a single data-loss issue.

Good for you.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> They are not hypothetical, believe me.  I have a lot gray hair to
> vouch for that, and too little time to waste on this again.

If you experienced problems, Magit/MSYSGit/Emacs maintainers will be
happy to address them.

>> I'm using MSYSGit + VC + Magit on Windows for several years and it never
>> caused a single data-loss issue.
>
> Good for you.

Thanks. I think it is important that people reading this ml should not
end under the impression that using Git on Windows is problematic.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 21:47:43 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > They are not hypothetical, believe me.  I have a lot gray hair to
> > vouch for that, and too little time to waste on this again.
> 
> If you experienced problems, Magit/MSYSGit/Emacs maintainers will be
> happy to address them.

These problems cannot be helped, because they stem from fundamental
incompatibilities between native and MSYS programs.

> I think it is important that people reading this ml should not end
> under the impression that using Git on Windows is problematic.

It's not problematic, but it has its annoyances.  I think it's
important that people reading this ml know the truth, even if it is
not entirely nice.

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

[David De La Harpe Golden]

On 03/01/14 20:12, Eli Zaretskii wrote:

> Thanks, I know about MSYS2.  My current MSYS environment is well tuned
> and satisfies me, so I feel no need to switch.
>
>

Just had a weird idea, though after searching looks like I mightn't have 
been the only one in history to have it [1]:

Have you ever tried jgit [2] on windows i.e. that pure java 
reimplementation of git?  It was mostly developed by and for use with 
Eclipse (ugh), but actually has its own little standalone command line 
interface. Not as featureful as real git, but pretty self-contained, it 
looks like it might have just about enough for a reasonable dev workflow 
on its own [3].

This is not a recommendation, I've never used the thing, might be a dead 
end, but OTOH might be worth a look.

[1] 
http://sandeep.wordpress.com/2010/09/13/using-git-on-windows-without-any-of-the-cygwinmsysgit-nonsense/

[2] http://www.eclipse.org/jgit/
[3] http://wiki.eclipse.org/JGit/User_Guide#Running_the_JGit_CLI

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

[Óscar Fuentes]

David De La Harpe Golden <david@harpegolden.net> writes:

> Just had a weird idea, though after searching looks like I mightn't
> have been the only one in history to have it [1]:
>
> Have you ever tried jgit [2] on windows i.e. that pure java
> reimplementation of git?  It was mostly developed by and for use with
> Eclipse (ugh), but actually has its own little standalone command line
> interface. Not as featureful as real git, but pretty self-contained,
> it looks like it might have just about enough for a reasonable dev
> workflow on its own [3].
>
> This is not a recommendation, I've never used the thing, might be a
> dead end, but OTOH might be worth a look.
>
> [1]
> http://sandeep.wordpress.com/2010/09/13/using-git-on-windows-without-any-of-the-cygwinmsysgit-nonsense/
>
> [2] http://www.eclipse.org/jgit/
> [3] http://wiki.eclipse.org/JGit/User_Guide#Running_the_JGit_CLI

First of all, I object against the FUD on the blog post [1]. For all
practical effects, there is nothing *nixy about Git on Windows (as
implemented by MSYSGit) You can use git.exe from a Windows command
prompt and you are not required to use the *nixy tools that comes with
the MSYSGit package.

Second, there are some great Emacs front-ends for git you can use on
Windows (Magit) and Emacs own VC works fine. Even if that java tool is
compatible with git's command-line options required by Emacs (something
I doubt) using it from Emacs would be damn slow, unless it supports some
type of server functionality where a single instance serves multiple
requests.

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

[Óscar Fuentes]

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

> 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,
[snip]

Emacs has some superb front-ends for git. They do a great job at hiding
the underlying UI. I loathe git command line but Magit is among the
tools that makes me enjoy my job.

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

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > I don't understand loving bzr; my experiences with it have been
 > unpleasant.

If you use basically centralized workflows (and Emacs's *is* basically
centralized -- that's why people bitch so much about feature freeze,
for example), bzr has a lot of optimizations for that.

 > 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 got that right.  I don't have any mixed feelings about it, though;
Bazaar does its best to prevent me from working the way I think, while
Mercurial got its colocated branching wrong, although the mq extension
makes up for that to a great extent.

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

[Stefan Monnier]

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

I've learned to appreciate Bzr and have trouble reproducing my
workflow with Git (especially the shared repository which Git seems only
able to somewhat approximate in a half-assed way, not mentioning the
lightweight checkouts which Git seems unable to handle).

But I really hope you don't die before Emacs switches to Git, because
I think this switch will happen pretty soon.


        Stefan

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

[Daniel Colascione]

On 01/02/2014 11:48 AM, Stefan Monnier wrote:
> I've learned to appreciate Bzr and have trouble reproducing my
> workflow with Git (especially the shared repository which Git seems only
> able to somewhat approximate in a half-assed way, not mentioning the
> lightweight checkouts which Git seems unable to handle).

What do you mean? git clone will use hardlinks when cloning a local 
repository, so it's very fast for me. Isn't speed (and some space 
efficiency) the reason to use bzr shared repositories?

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

[Stefan Monnier]

>> I've learned to appreciate Bzr and have trouble reproducing my
>> workflow with Git (especially the shared repository which Git seems only
>> able to somewhat approximate in a half-assed way, not mentioning the
>> lightweight checkouts which Git seems unable to handle).
> What do you mean? git clone will use hardlinks when cloning a local
> repository, so it's very fast for me.

Yes, it's shared when you "git clone" but 3 years down the line, there's
not much sharing left.  I.e. the sharing is only approximated.

> Isn't speed (and some space efficiency) the reason to use bzr
> shared repositories?

Yes, speed and space (inefficient space usage is a problem both for
speed and for backup purposes).


        Stefan

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

[David De La Harpe Golden]

On 02/01/14 21:05, Stefan Monnier wrote:

> Yes, it's shared when you "git clone" but 3 years down the line, there's
> not much sharing left.  I.e. the sharing is only approximated.
>

Hmm. Is it really git-new-workdir you're wanting? So you can have a few 
working trees for different branches from the one repo live at once?

On a typical debian box, it'll be squirreled away in
/usr/share/doc/git/contrib/workdir/git-new-workdir

(along with a whole bunch of other sorta-useful probably-working things 
that haven't quite made it into git's grab-bag of official commands.)

Someone's got a blog post here about it:

http://nuclearsquid.com/writings/git-new-workdir/

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

[Andreas Schwab]

David De La Harpe Golden <david@harpegolden.net> writes:

> Hmm. Is it really git-new-workdir you're wanting? So you can have a few
> working trees for different branches from the one repo live at once?
>
> On a typical debian box, it'll be squirreled away in
> /usr/share/doc/git/contrib/workdir/git-new-workdir

FWIW, there is work in progress making git new-workdir a first class git
citizen (ie. moving its functionality to git-core and fixing its
shortcomings).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Stefan Monnier]

> Hmm.  Is it really git-new-workdir you're wanting?

Yes, but without its shortcomings.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
> Date: Thu, 02 Jan 2014 14:48:56 -0500
> 
> But I really hope you don't die before Emacs switches to Git

I might die of sadness.

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

[joakim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Karl Fogel <kfogel@red-bean.com>,  emacs-devel@gnu.org
>> Date: Thu, 02 Jan 2014 14:48:56 -0500
>> 
>> But I really hope you don't die before Emacs switches to Git
>
> I might die of sadness.
>

Keeping Eli happy is imho a pretty important use case for the vcs used
by Emacs. No, really. We don't have many hard-core contributors.

I prefer git, but I think I get along pretty well with the git-bzr
bridge.

Perhaps it would be possible to use bzr on top of a git repo, such that
everyone can be happy?
-- 
Joakim Verona

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

[Eli Zaretskii]

> From: joakim@verona.se
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  kfogel@red-bean.com,  emacs-devel@gnu.org
> Date: Fri, 03 Jan 2014 07:33:00 +0100
> 
> Keeping Eli happy is imho a pretty important use case for the vcs used
> by Emacs. No, really. We don't have many hard-core contributors.

Thank you.

> Perhaps it would be possible to use bzr on top of a git repo, such that
> everyone can be happy?

No, this isn't workable.  I tried that in the past with several git
repositories.  The bzr-git plugin is unfinished (the biggest
shortcoming is that it doesn't support pushing), and its developer
officially announced he no longer works on it.

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

[Juanma Barranquero]

On Fri, Jan 3, 2014 at 7:33 AM,  <joakim@verona.se> wrote:

> Keeping Eli happy is imho a pretty important use case for the vcs used
> by Emacs. No, really. We don't have many hard-core contributors.

+1

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

[Bastien]

It seems to me that this thread is taking a wrong path:
it started as "please use Git" and continues as "please
keep Eli."

Maybe Eli if you could suggest an alternative to bzr
(that is not Git, which you hate) people would be open
to your suggestions?

I for one would be open to using another dVCS as long
as it makes current contributors happier and allows to
get more contributions.

-- 
 Bastien

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

[David Engster]

Bastien writes:
> It seems to me that this thread is taking a wrong path:
> it started as "please use Git" and continues as "please
> keep Eli."

It's exactly the right path. There's a real danger of reducing the
productivity of one of the most important core developers.

> I for one would be open to using another dVCS as long
> as it makes current contributors happier and allows to
> get more contributions.

I predict there won't be a significant increase in new
contributions. The real hurdles to participate in Emacs development lie
elsewhere.

-David

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

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Fri, 03 Jan 2014 14:46:56 +0100
> Cc: Juanma Barranquero <lekktu@gmail.com>, Joakim Verona <joakim@verona.se>,
> 	Emacs developers <emacs-devel@gnu.org>, Karl Fogel <kfogel@red-bean.com>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
> 
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development
> lie elsewhere.

I'm afraid you are right.  What's more, I don't see new people coming
aboard who would advance Emacs into the future (as opposed to
contributing minor improvements and bugfixes -- which are, of course,
important as well).  I hope I'm wrong, and they will come, with or
without git.

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

[Tom]

David Engster <deng <at> randomsample.de> writes:
> 
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development lie
> elsewhere.

The more roadblocks are removed the better.

There were several people in this thread who said bzr kept them 
from contributing. (Unfamiliar DVCS while git is becoming the
DVCS which is pretty much known by everyone these days.)

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

[David Engster]

Tom writes:
> David Engster <deng <at> randomsample.de> writes:
>> 
>> I predict there won't be a significant increase in new
>> contributions. The real hurdles to participate in Emacs development lie
>> elsewhere.
>
> The more roadblocks are removed the better.

Well, the switch will happen, so let's just wait and see. I'd love to be
proven wrong.

> There were several people in this thread who said bzr kept them 
> from contributing.

No offense to those guys, but in my book, Eli's vote counts more.

-David

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

[Eric S. Raymond]

David Engster <deng@randomsample.de>:
> I predict there won't be a significant increase in new
> contributions. The real hurdles to participate in Emacs development lie
> elsewhere.

It's not "or", but "and".

The fact that there are other reasons contribution is difficult (and yes, I 
have a fairly long list in mind) does not mean that the friction losses 
inflicted by bzr are acceptable.

We have direct testimony in this thread from two people who wanted to
contribute but found bzr a crash landing.
-- 
		<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]

> From: Bastien <bzg@gnu.org>
> Cc: Joakim Verona <joakim@verona.se>,  Karl Fogel <kfogel@red-bean.com>,  Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  Emacs developers <emacs-devel@gnu.org>
> Date: Fri, 03 Jan 2014 14:01:19 +0100
> 
> It seems to me that this thread is taking a wrong path:
> it started as "please use Git" and continues as "please
> keep Eli."

I didn't feel it was that way.  Karl asked for opinions and I provided
mine.  I hope no one, including Karl, expected to hear only the YES
kind of responses.  I didn't ask anyone to please me, and didn't say I
will stop working on Emacs if it did switch.

> Maybe Eli if you could suggest an alternative to bzr
> (that is not Git, which you hate) people would be open
> to your suggestions?

I don't see the need.  Either we switch to git or we don't, it's that
simple.  No one will switch to anything else.

> I for one would be open to using another dVCS as long
> as it makes current contributors happier and allows to
> get more contributions.

As someone else said, git sucked all the oxygen there was, so here we
are.  As for more contributions, I hope you are right, but I have my
doubts.

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

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't ask anyone to please me, and didn't say I
> will stop working on Emacs if it did switch.

Okay.  It was suggested that the switch would discourage
you from contributing, I'm glad to read otherwise.

>> Maybe Eli if you could suggest an alternative to bzr
>> (that is not Git, which you hate) people would be open
>> to your suggestions?
>
> I don't see the need.  Either we switch to git or we don't, it's that
> simple.  No one will switch to anything else.

(I thought Mercurial was another possible choice.)

>> I for one would be open to using another dVCS as long
>> as it makes current contributors happier and allows to
>> get more contributions.
>
> As someone else said, git sucked all the oxygen there was, so here we
> are.  As for more contributions, I hope you are right, but I have my
> doubts.

I don't think we will magically get tons of new contributors,
but I know that past contributors like Thierry V. and John W.
said they are more likely to contribute back again, which
already counts as "more contributors" for me.

-- 
 Bastien

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

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> I don't think we will magically get tons of new contributors,
> but I know that past contributors like Thierry V. and John W.
> said they are more likely to contribute back again, which
> already counts as "more contributors" for me.

Another one of those people is me.

There are other reasons I've been inactive, but I too have found 
bzr a significant blocker.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Antonio Nikishaev]

Eli Zaretskii <eliz@gnu.org> writes:

>> Maybe Eli if you could suggest an alternative to bzr
>> (that is not Git, which you hate) people would be open
>> to your suggestions?
>
> I don't see the need.  Either we switch to git or we don't, it's that
> simple.  No one will switch to anything else.

There is hg. It's pretty popular.

(And it has nice ui and far less wtfs than git)

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

[Stephen J. Turnbull]

Antonio Nikishaev writes:

 > There is hg. It's pretty popular.

True, but it doesn't have the momentum of git.

 > (And it has nice ui and far less wtfs than git)

Git has not WTF'ed me since the first week I used it.  But then, I
thought the concept was cool and read the whole theory of operations
part of the old man page (several times until I understood it).  Most
developers don't want to do that, which is not a problem.  But many of
those developers also want git to fit their preconceptions, which it
doesn't, and that is a problem.

Mercurial, OTOH, has several WTFs, sufficiently F-ed up that I don't
ever use the corresponding features ("named branches", rebase, there
are several others less important).

I also don't really understand the complaints about the git CLI.  I
have a fairly complex set of practices in git, but I use the same
number of commands and *fewer* options in git than I do in hg or bzr.
(This can be improved by using plugins.)  And when I want to do
something complex in git (like filter-branch), I *can* do it, whereas
I can't in hg or bzr.

I'll grant that git's ref-relative commit addressing (including the
whole ref algebra of HEAD^2~6^3) was a bit disconcerting at first, but
it saves me substantial keystrokes compared to the bzr and hg
equivalents (not to mention a lot of screen space that isn't used up
with log or id commands to get hold of a revno).

It's true that Bazaar has some useful features, such as shared repos,
whose performance characteristics are hard to emulate accurately in
git.  I can't speak to Stefan's experience, of course, but when I look
at my git repos, in fact sharing is quite high because branches in
separate repos tend to be very divergent (so only the original shared
objects *can* be shared), and when the main feature branch gets
merged, the whole repo usually gets deleted so the failure of "git
fetch" to hardlink pulled objects isn't a big space leak.  I also
periodically clean up dormant branches by pulling them into a
"warehouse" repo, and then deleting the separate repo.  (I have plenty
of space, this is to clean up the directory listing, not the disk
usage.  But it sure helps conserve disk.)

The only bzr features that I don't see how to emulate effectively in
git are "log -n ...", bound branches, and lightweight checkouts.  But
I've never missed them in git.  I suspect that when the move to git
happens, Stefan will find alternative, functionally equivalent,
workflows appropriate to git after a while.  Unfortunately I can't
promise that.  (In the case of log -n, I far prefer the graphical DAG
displays anyway.)

Steve

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

[Barry Warsaw]

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

On Jan 04, 2014, at 05:15 AM, Stephen J. Turnbull wrote:

>It's true that Bazaar has some useful features, such as shared repos,
>whose performance characteristics are hard to emulate accurately in
>git.  I can't speak to Stefan's experience, of course, but when I look
>at my git repos, in fact sharing is quite high because branches in
>separate repos tend to be very divergent (so only the original shared
>objects *can* be shared), and when the main feature branch gets
>merged, the whole repo usually gets deleted so the failure of "git
>fetch" to hardlink pulled objects isn't a big space leak.

I know Stephen knows this, but Bazaar shared repos are really just a way to
efficiently store revision objects in a parent directory, such that you can
have a number of subdirectories inside there that represent working
directories of different branches.  Or put it another way, it just moves the
.bzr directory up one level so everything underneath it can share that.  In
most cases, most branches share probably 90% of their revisions, and that's
what makes local branching and remote pulling into a shared repo pretty fast.

I'm another big bzr fan, and while colocated branches are interesting, I find
them to be completely counter to my way of working.  If I'm going to be
working on a number of branches, I want separate working directories for each.
So for example, in Mailman (under bzr) I'll have a shared repo directory
containing working directories each containing a different in-progress feature
(topic) branch.

For Python hg's and other projects git repos, I basically have multiple clones
inside a parent directory that's nothing special.  It works, but doesn't map
to my way of working as well as bzr.

The other thing I sorely miss when working with git repositories is bzr's main
line of development approach.  Once you understand this, and use it correctly
(i.e. merges in the right direction), it's a very nice simplifying feature.
It allows you to have human friendly revision numbers[1], with dotted revision
numbers for side branches.  More importantly, it means that there's no cultural
pressure for history changing rebases, `bzr log` by default only follows the
main line (so side branches are hidden by default, unless you *want* to see
them), and bisect doesn't make you unhappy by landing you in non-working
revisions.

I think if git had this concept and --help text that wasn't 20 pages long (629
lines for `git merge --help`!) it would go a long way to improving the user
friendliness of git, IMHO of course.

That said, it's pretty clear that git has won this round of dVCS wars.
Mercurial will probably hang on and hopefully even thrive as a viable
alternative, but network effects have given git most of the mindshare.  At
least until something better comes along, as it has with CVS and svn in their
times.

-Barry

[1] Yes, they are local-only, and yes they can change, and yes you still have
unique hashes to unambiguously reference a revision, but it's still darn
convenient.  I'd much rather say "Are you on revision 7250 of branch
lp:mailman?"

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Karl Fogel]

Eli Zaretskii <eliz@gnu.org> writes:
>I didn't feel it was that way.  Karl asked for opinions and I provided
>mine.  I hope no one, including Karl, expected to hear only the YES
>kind of responses.  I didn't ask anyone to please me, and didn't say I
>will stop working on Emacs if it did switch.

Eli's response was exactly the kind of information I was hoping to
elicit, yes.

I also agree that a vote from someone like Eli should somehow count more
than a vote from (say) me.  But even adjusting for that, the total vote
weight in favor of switching to git is still pretty clear in this
thread, as others have noted.

>I don't see the need.  Either we switch to git or we don't, it's that
>simple.  No one will switch to anything else.

That does seem right.

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

[Stefan Monnier]

> Maybe Eli if you could suggest an alternative to bzr
> (that is not Git, which you hate) people would be open
> to your suggestions?

That would be pointless.  As it stands currently, it's either Bzr
or Git.  The arguments in favor of Git aren't technical but social and
I can't see any other VCS where similar social pressure applies.

From where I stand, it seems pretty clear that Emacs will switch to Git,
the only remaining question is when.


        Stefan

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

[Ted Zlatanov]

On Fri, 03 Jan 2014 09:54:39 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> From where I stand, it seems pretty clear that Emacs will switch to Git,
SM> the only remaining question is when.

After the code freeze?  Pleeze?

Ted

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

[Karl Fogel]

Ted Zlatanov <tzz@lifelogs.com> writes:
>On Fri, 03 Jan 2014 09:54:39 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
>SM> From where I stand, it seems pretty clear that Emacs will switch to Git,
>SM> the only remaining question is when.
>
>After the code freeze?  Pleeze?

+1.  No need for us to pick gratuitously inconvenient timing.

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

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

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

I have no fondness for git (it has a way of complicating things
unnecessarily), but I do think it would be a good idea to switch over.
And if we do make the switch, I hope your hope doesn't come true.  >"?

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

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

[Ted Zlatanov]

On Thu, 02 Jan 2014 23:31:19 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

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

LMI> I have no fondness for git (it has a way of complicating things
LMI> unnecessarily), but I do think it would be a good idea to switch over.
LMI> And if we do make the switch, I hope your hope doesn't come true.  >"?

Predictably, I'm strongly in favor of moving to Git.  Besides the things
listed already, I think it will make the life of Katsumi Yamaoka, who
tirelessly synchronizes commits between Gnus and Emacs, a bit easier
when both those projects are using Git.

Ted

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

[David Engster]

Ted Zlatanov writes:
> Besides the things listed already, I think it will make the life of
> Katsumi Yamaoka, who tirelessly synchronizes commits between Gnus and
> Emacs, a bit easier when both those projects are using Git.

It should at least be noted that CEDET is using bzr, and when Emacs
switches, we will probably have to do that as well; not really for
technical reasons, but simply to not be the last man standing.

I don't see which advantages git has w.r.t. cross-repository merges. It
really boils down to playing the patch|diff game.

-David

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

[Christoph]

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

On Thu, Jan 2, 2014 at 8:41 AM, Karl Fogel <kfogel@red-bean.com> wrote:

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

+1 for git.

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

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

[Bozhidar Batsov]

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

+1 from me for migration to git.

On 2 January 2014 17:41, Karl Fogel <kfogel@red-bean.com> wrote:

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

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

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

[Daniel Colascione]

On 01/02/2014 07:41 AM, Karl Fogel wrote:
> 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.

+1 for git. Mercurial would be acceptable as well, but I prefer git: hg 
got branching wrong and git got it right. Sure, git's UI is finnicky, 
but it's the emerging standard, and there's an incredibly rich ecosystem 
built around it.

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

[Paul Eggert]

+1 for git as well.  It has its flaws but it's significantly better
for my usage.  Disclaimer: I'm biased, as the lead git developer
is a friend of mine.

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

[Michael Albinus]

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

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

+1 for git. No tremendous technical reason (I can live with any VCS
supported by vc.el), but Tramp lives already in git, and the sync
between Tramp and Emacs might be easier then.

> -Karl

Best regards, Michael.

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

[Xue Fuqiao]

On Thu, Jan 2, 2014 at 11:41 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> 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?

+1 for using Git.  IIRC there are major bugs which have been in their
bug-tracker for years now.

And this problem has troubled me for a long time:
http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/75075

-- 
http://www.gnu.org/software/emacs/

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

[Stephen Eglen]

On Thu, Jan 02 2014, Karl Fogel wrote:

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

+1 for git.

John Wiegley's posts in this thread convinced me of this last year, and
it seems nothing has changed to weaken the usefulness of git.

  http://comments.gmane.org/gmane.emacs.devel/158242

Stephen

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

[Thierry Volpiatto]

+1 for git.
I have stopped contributing to emacs to avoid using bzr.
I have even removed myself from emacs savanah.
Also would be great to stop writing unuseful changelog files.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

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

[Michael Albinus]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Also would be great to stop writing unuseful changelog files.

They are useful. A tar distribution does not contain the git repo with
the history of commitments.

Another question is, whether we still want to write ChangeLogs manually,
or whether we want to extract them from commit comments. That's not such
easy, see all the "fix typo" comments.

Best regards, Michael.

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

[Thierry Volpiatto]

Michael Albinus <michael.albinus@gmx.de> writes:

> They are useful. A tar distribution does not contain the git repo with
> the history of commitments.

Not sure people getting their emacs from tarball read changelog files...
Anyway they can read these infos online.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

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

[Bastien]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> They are useful. A tar distribution does not contain the git repo with
>> the history of commitments.
>
> Not sure people getting their emacs from tarball read changelog
> files...

I do, when testing release candidates.

> Anyway they can read these infos online.

Grep'ing through Changelogs is really fast, and thanks to the
uniformity of style, really useful.  I know I can grep through
commit messages using git grep (or magit, FWIW), but there is
a layer of UI between me and the Changelogs then.

-- 
 Bastien

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

[Bastien]

Michael Albinus <michael.albinus@gmx.de> writes:

> They are useful. A tar distribution does not contain the git repo with
> the history of commitments.

+1.

> Another question is, whether we still want to write ChangeLogs manually,
> or whether we want to extract them from commit comments. That's not such
> easy, see all the "fix typo" comments.

I'm all for writing them manually, it's a useful exercise.

IMHO git commit messages should reproduce ChangeLogs, not the
other way around.

-- 
 Bastien

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

[Rüdiger Sonderfeld]

On Friday 03 January 2014 10:17:00 Bastien wrote:
> > Another question is, whether we still want to write ChangeLogs manually,
> > or whether we want to extract them from commit comments. That's not such
> > easy, see all the "fix typo" comments.
> 
> I'm all for writing them manually, it's a useful exercise.
> 
> IMHO git commit messages should reproduce ChangeLogs, not the
> other way around.

Generating them from commit messages would do exactly that.  Right now most 
people copy all or at least parts of the ChangeLog entry to the commit message 
anyway.  I agree that the format is useful and I absolutely agree that the 
commit message should not necessarily only be a copy of the ChangeLog entry.

But those points are not really an obstacle or argument against auto-
generation of the ChangeLog _files_ from the commit messages

Regards,
Rüdiger

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

[Daniel Colascione]

On 01/03/2014 01:35 AM, Rüdiger Sonderfeld wrote:
> On Friday 03 January 2014 10:17:00 Bastien wrote:
>>> Another question is, whether we still want to write ChangeLogs manually,
>>> or whether we want to extract them from commit comments. That's not such
>>> easy, see all the "fix typo" comments.
>>
>> I'm all for writing them manually, it's a useful exercise.
>>
>> IMHO git commit messages should reproduce ChangeLogs, not the
>> other way around.
>
> Generating them from commit messages would do exactly that.  Right now most
> people copy all or at least parts of the ChangeLog entry to the commit message
> anyway.  I agree that the format is useful and I absolutely agree that the
> commit message should not necessarily only be a copy of the ChangeLog entry.
>
> But those points are not really an obstacle or argument against auto-
> generation of the ChangeLog _files_ from the commit messages

It's a lot safer to fix an error in ChangeLog than to interactively 
rebase and force-push a new history. Would this automated ChangeLog 
generation system be tolerant of manual ChangeLog editing?

If we're going to have ChangeLog files anyway, we're still going to have 
to deal with merging. Since we have to write change descriptions in any 
case and since we already have mature tools for making ChangeLog 
additions, we might as well retain the current system. It would be nice, 
though, to auto-fill commit messages based on ChangeLog deltas.

By the way: git-merge-changelog from gnulib looks useful.

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

[Eli Zaretskii]

> Date: Fri, 03 Jan 2014 01:53:05 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: Bastien <bzg@gnu.org>, Michael Albinus <michael.albinus@gmx.de>,
> 	Thierry Volpiatto <thierry.volpiatto@gmail.com>
> 
> By the way: git-merge-changelog from gnulib looks useful.

Yes.  And a native Windows binary is available, if anyone is
interested.

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

[Stephen J. Turnbull]

Daniel Colascione writes:

 > It's a lot safer to fix an error in ChangeLog than to interactively 
 > rebase and force-push a new history. Would this automated ChangeLog 
 > generation system be tolerant of manual ChangeLog editing?

git help notes

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

[Bastien]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> But those points are not really an obstacle or argument against auto-
> generation of the ChangeLog _files_ from the commit messages

Commit messages are not meant to be edited, while it's good to be
able to edit Changelog files.

We use the workflow you suggest in Org (i.e. using only commit
messages and producing ChangeLogs from them) and I can tell how
frustrating this is: you need to review all typos and mistakes
from all contributors, because the script to generate the logs
will not do it for you.

-- 
 Bastien

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

[Tassilo Horn]

Bastien <bzg@gnu.org> writes:

>> Another question is, whether we still want to write ChangeLogs
>> manually, or whether we want to extract them from commit comments.
>> That's not such easy, see all the "fix typo" comments.
>
> I'm all for writing them manually, it's a useful exercise.

The problem with ChangeLog files is that they provoke conflicts.

When I contribute to some git-using project that has manually written
ChangeLog files, I usually create a new branch, do my changes, write a
ChangeLog entry in a _temporary_ buffer, and then commit providing a
one-line description plus the ChangeLog entries (without the author/date
headline).

Then I sometimes rebase that branch onto master (which works just fine
since the ChangeLog hasn't been changed) until upstream is satisfied
with my changes.  At that point, I put my commit message as real entry
into the ChangeLog, commit, squash the ChangeLog commit with the commit
implementing my changes, and finally push/submit the patch/send the pull
request.

That said, bzr with its changelog_merge plugin is nice, too.  Then you
can make a real, persistent ChangeLog entry along with your commit
implementing the code changes, but once you merge your branch into trunk
you have to remember to pull your entry to the top of the ChangeLog and
re-date it.

Bye,
Tassilo

Generating ChangeLog files.

[Rüdiger Sonderfeld]

On Friday 03 January 2014 08:39:04 Michael Albinus wrote:
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
> > Also would be great to stop writing unuseful changelog files.
> 
> They are useful. A tar distribution does not contain the git repo with
> the history of commitments.
> 
> Another question is, whether we still want to write ChangeLogs manually,
> or whether we want to extract them from commit comments. That's not such
> easy, see all the "fix typo" comments.

I think we should generate the ChangeLogs from commit messages.  I know that 
one argument raised in the past was that the commit message and ChangeLog can 
differ.  But I don't see a reason why it shouldn't be possible to have both in 
the commit message.  Only the ChangeLog part is added to the generated 
ChangeLog.  This would also allow "fix typo" commits not to be added.

IMO ChangeLogs are an atavism from times when VCS's were not as sophisticated 
as today.  They cause more problems for developers than they are useful.  A 
modern VCS provides tools to more easily match changes to commits than 
searching a ChangeLog can.  They are a pain when merging or rebasing patches.  
I usually write patches on a branch and rebase them when they are ready to be 
pushed.  This always causes merge conflicts for the ChangeLog.  (Maybe [1] 
could help a bit.)

E.g., GNU Octave replaced ChangeLog with an auto-generated ChangeLog from 
commit messages and they seem to be quite happy with that solution.

I know the topic has been discussed several times and it seems a bit pointless 
to start the discussion again.  But in my opinion ChangeLogs are an even 
bigger issue than the VC because at least I can work around the latter by 
using git-bzr.

[1] http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c

Regards
Rüdiger

Re: Generating ChangeLog files.

[Eli Zaretskii]

> From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> Date: Fri, 03 Jan 2014 10:31:39 +0100
> Cc: Michael Albinus <michael.albinus@gmx.de>,
> 	Thierry Volpiatto <thierry.volpiatto@gmail.com>
> 
> I usually write patches on a branch and rebase them when they are ready to be 
> pushed.  This always causes merge conflicts for the ChangeLog.  (Maybe [1] 
> could help a bit.)

There should be no merge conflicts with ChangeLog files.  I see an
absolute zero of them.  git-merge-changelog and the changelog_merge
plugin in bzr make this not an issue.

> E.g., GNU Octave replaced ChangeLog with an auto-generated ChangeLog from 
> commit messages and they seem to be quite happy with that solution.

I've seen a couple of projects that eliminated ChangeLogs.  In every
single case, the result was a drastic deterioration in the quality of
the commit log information.

> I know the topic has been discussed several times and it seems a bit pointless 
> to start the discussion again.  But in my opinion ChangeLogs are an even 
> bigger issue than the VC because at least I can work around the latter by 
> using git-bzr.

As pointed out above, you should be able to resolve the former as
well, in no time.

Re: Generating ChangeLog files.

[Bozhidar Batsov]

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

On 3 January 2014 12:12, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Rüdiger Sonderfeld <ruediger@c-plusplus.de>
> > Date: Fri, 03 Jan 2014 10:31:39 +0100
> > Cc: Michael Albinus <michael.albinus@gmx.de>,
> >       Thierry Volpiatto <thierry.volpiatto@gmail.com>
> >
> > I usually write patches on a branch and rebase them when they are ready
> to be
> > pushed.  This always causes merge conflicts for the ChangeLog.  (Maybe
> [1]
> > could help a bit.)
>
> There should be no merge conflicts with ChangeLog files.  I see an
> absolute zero of them.  git-merge-changelog and the changelog_merge
> plugin in bzr make this not an issue.
>
> > E.g., GNU Octave replaced ChangeLog with an auto-generated ChangeLog from
> > commit messages and they seem to be quite happy with that solution.
>
> I've seen a couple of projects that eliminated ChangeLogs.  In every
> single case, the result was a drastic deterioration in the quality of
> the commit log information.
>

I work on a lot of open-source projects and most them have changelogs
listing only non-trivial changes (as opposed to what
we do in Emacs - listing everything). While I definitely think a changelog
is usefu,l I don't think it's particularly
good idea to simply copy the commit messages in the changelog (or vice
versa). IMO the changelog should
strike some middle ground between the NEWS and the commit log. As it stands
now - it's mostly a duplication of
the commit log, so I rarely refer to it.


>
> > I know the topic has been discussed several times and it seems a bit
> pointless
> > to start the discussion again.  But in my opinion ChangeLogs are an even
> > bigger issue than the VC because at least I can work around the latter by
> > using git-bzr.
>
> As pointed out above, you should be able to resolve the former as
> well, in no time.
>
>
>

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

Re: Generating ChangeLog files.

[Juanma Barranquero]

On Fri, Jan 3, 2014 at 7:09 PM, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> As it stands
> now - it's mostly a duplication of
> the commit log, so I rarely refer to it.

ChangeLogs are easier to access and search, and they have better
information (mistakes can be corrected). I rarely refer to the commit
log, other than the one-liners of "bzr log --line" to quickly locate a
recent commit, and these are less than helpful because many people
does not really adds a summary.

So count this as a strong +1 for keeping ChangeLogs.

   J

Re: Generating ChangeLog files.

[Stefan Monnier]

>> As it stands now - it's mostly a duplication of the commit log, so
>> I rarely refer to it.

It is a duplication, and that's on purpose.  The purpose being to
eventually be able to auto-generate the ChangeLog.

> ChangeLogs are easier to access and search, and they have better
> information (mistakes can be corrected).  I rarely refer to the commit
> log, other than the one-liners of "bzr log --line" to quickly locate a
> recent commit, and these are less than helpful because many people
> does not really adds a summary.

I stand on the other side: the only reason I ever look at the ChangeLog
files is because "bzr log" is so damn slow.  But even with this
slowness, I usually use "bzr log" (or rather vc-print-log), because
I can then easily get the corresponding diff.


        Stefan

Re: Generating ChangeLog files.

[Kenichi Handa]

In article <jwvppo8subg.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > ChangeLogs are easier to access and search, and they have better
> > information (mistakes can be corrected).  I rarely refer to the commit
> > log, other than the one-liners of "bzr log --line" to quickly locate a
> > recent commit, and these are less than helpful because many people
> > does not really adds a summary.

> I stand on the other side: the only reason I ever look at the ChangeLog
> files is because "bzr log" is so damn slow.  But even with this
> slowness, I usually use "bzr log" (or rather vc-print-log), because
> I can then easily get the corresponding diff.

I, in general, prefer ChangeLog files, but one point I don't
like it is that they are splitted into multiple directories.
I'd like to see all related changes for a single commit as a
single ChangeLog entry.  Isn't it possible to have a single
ChangeLog file in the top directory?

---
Kenichi Handa
handa@gnu.org

Re: Generating ChangeLog files.

[Paul Eggert]

Kenichi Handa wrote:
> I'd like to see all related changes for a single commit as a
> single ChangeLog entry.  Isn't it possible to have a single
> ChangeLog file in the top directory?

I'd also prefer this.  I use vc-dwim to generate commit
logs automatically from ChangeLog entries.  It works better
when it doesn't have to merge ChangeLog entries from different
files.  I don't see much advantage to having ChangeLog files
all over the place; one per project is simpler and better.

Re: Generating ChangeLog files.

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

The reason I put separate change log files in several directories was
just so they would be somewhat shorter, so each one would be less
cumbersome to look through.  Most changes are limited to one of
the change log files.  A few changes include some Lisp code and some C code,
but since they are a small fraction, they didn't cancel out the benefit.

-- 
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: Generating ChangeLog files.

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: lekktu@gmail.com, emacs-devel@gnu.org,
> 	ruediger@c-plusplus.de,
> 	michael.albinus@gmx.de,
> 	bozhidar@batsov.com,
> 	thierry.volpiatto@gmail.com,
> 	eliz@gnu.org
> Date: Sat, 04 Jan 2014 12:49:34 +0900
> 
> Isn't it possible to have a single ChangeLog file in the top
> directory?

It's definitely possible technically, add-change-log-entry already
searches for a ChangeLog file up the directory tree.

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

[Stefan Monnier]

>> Also would be great to stop writing unuseful changelog files.
> They are useful.  A tar distribution does not contain the git repo with
> the history of commitments.

Please let's not rehash old arguments: the tarball contains many files
that are generated, so it would be trivial to include the "git log"
output in it.


        Stefan

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

[Bastien]

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

> Please let's not rehash old arguments: the tarball contains many files
> that are generated, so it would be trivial to include the "git log"
> output in it.

How would we handle fixing in such generated logs?
By revising the git history through rebasing?

Not a rhetorical question, just curious, as I do have a
problem with the current way Org generates its ChangeLogs.

-- 
 Bastien

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

[Achim Gratz]

Bastien writes:
> How would we handle fixing in such generated logs?

The same way we do today if we only care about the Changelog file.
Otherwise, we'd have to come up with something using Git notes (as
already mentioned earlier in this thread).

> By revising the git history through rebasing?

Nope.

> Not a rhetorical question, just curious, as I do have a
> problem with the current way Org generates its ChangeLogs.

For the benefit of other participants in this discussion you might
mention that Org doesn't have a ChangeLog and the only reason we
generate one is that when changes are imported into Emacs there is
suddenly a need to document that merge (typically produced by ~1000
commits from Org) in Emacs' ChangeLog.  Since that operation throws away
all history from Org, it also means you can't use the commit messages
directly for the ChangeLog, no matter how hard you'd wish you could.
That wouldn't necessarily be a problem in Emacs' case where the
correspondence between commit and ChangeLog would be 1:1.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> How would we handle fixing in such generated logs?
>
> The same way we do today if we only care about the Changelog file.

We don't do "it" today.

Org ChangeLogs are generated using a script, and these changelogs are
added to Emacs when we merge Org.  It's fine fixing these changelogs
manually because newly generated Changelogs don't overwrite previous
ones.

My question is: if Emacs generates Changelogs from commit messages,
and if commit messages contain ill-formated changelogs, how do you
fix generated changelogs?

One idea is to generate only new changes (and fix them manually if
needed), not to generate all ChangeLogs.

> Otherwise, we'd have to come up with something using Git notes (as
> already mentioned earlier in this thread).
>
>> By revising the git history through rebasing?
>
> Nope.
>
>> Not a rhetorical question, just curious, as I do have a
>> problem with the current way Org generates its ChangeLogs.
>
> For the benefit of other participants in this discussion you might
> mention that Org doesn't have a ChangeLog

I did: http://article.gmane.org/gmane.emacs.devel/167136

> and the only reason we
> generate one is that when changes are imported into Emacs there is
> suddenly a need to document that merge (typically produced by ~1000
> commits from Org) in Emacs' ChangeLog.  Since that operation throws away
> all history from Org, it also means you can't use the commit messages
> directly for the ChangeLog, no matter how hard you'd wish you could.

It's a matter of convention: if Emacs generates Changelog files from
commit messages, I guess we will enforce some policy on how to write
suitable commit messages.

Additional (not suitable for ChangeLogs) information could then be
stored in git notes.

> That wouldn't necessarily be a problem in Emacs' case where the
> correspondence between commit and ChangeLog would be 1:1.

Yes.

-- 
 Bastien

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

[Achim Gratz]

Bastien writes:
> My question is: if Emacs generates Changelogs from commit messages,
> and if commit messages contain ill-formated changelogs, how do you
> fix generated changelogs?

If you've got a version-controlled ChangeLog file (status quo), it is
completely immaterial of how the entries are produced.  Even if they are
all generated, you can still edit the file, just as you've done all the
time.

> One idea is to generate only new changes (and fix them manually if
> needed), not to generate all ChangeLogs.

Generating all ChangeLogs is superfluous since then you don't need a
ChangeLog at all.

> It's a matter of convention: if Emacs generates Changelog files from
> commit messages, I guess we will enforce some policy on how to write
> suitable commit messages.

Again, this is an argument to abolish ChangeLogs altogether.

> Additional (not suitable for ChangeLogs) information could then be
> stored in git notes.

Git notes are simply a way to augment or correct the original commit
message (which can't be separated from the commit without rewriting
history).  As such it should be used sparingly, if at all.  I'd rather
have code review that ensures the commit messages are good than git
notes.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> If you've got a version-controlled ChangeLog file (status quo), it is
> completely immaterial of how the entries are produced.  Even if they are
> all generated, you can still edit the file, just as you've done all the
> time.

I wish I didn't have to do it all the time, hence my question.

-- 
 Bastien

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

[Stefan Monnier]

> Generating all ChangeLogs is superfluous since then you don't need a
> ChangeLog at all.

Hello?  This thread is about removing Emacs's ChangeLog files because
they are (by design) redundant.


        Stefan

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

[Florian Weimer]

* Bastien:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Please let's not rehash old arguments: the tarball contains many files
>> that are generated, so it would be trivial to include the "git log"
>> output in it.
>
> How would we handle fixing in such generated logs?
> By revising the git history through rebasing?

There's also "git notes".  It would provide a clean way of amending
log entries, but I haven't seen it used in the wild yet.

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

[Eric S. Raymond]

Thierry Volpiatto <thierry.volpiatto@gmail.com>:
> Also would be great to stop writing unuseful changelog files.

+1.  But that's the next battle, not this one.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

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

Our ChangeLog files are very useful in debugging.
They complement the diffs between versions of the source files.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> Our ChangeLog files are very useful in debugging.
> They complement the diffs between versions of the source files.

I think everyone agrees with this.

The question is whether we should edit them separately
from the commit messages, or if we should produce them
by (programmatically) extracting them from the commit
messages.

-- 
 Bastien

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

[Eric S. Raymond]

Bastien <bzg@gnu.org>:
> Richard Stallman <rms@gnu.org> writes:
> 
> > Our ChangeLog files are very useful in debugging.
> > They complement the diffs between versions of the source files.
> 
> I think everyone agrees with this.

I don't.  I think Changelogs are, while not completely without value,
not worth the maintainance load when your VCS has changesets.  I've
seem the same objection from others in the discussion.  But this is a
separate argument from which DVCS we should be using.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

[Lars Magne Ingebrigtsen]

Bastien <bzg@gnu.org> writes:

> The question is whether we should edit them separately
> from the commit messages, or if we should produce them
> by (programmatically) extracting them from the commit
> messages.

If we decided on having a vc-log commit mode for Emacs that would
enforce the ChangeLog style, then that would be interesting.  But I
don't really see a super-obvious way of implementing that.

Here's a typical ChangeLog entry from a single commit (I think):

2013-12-27  Stefan Monnier  <monnier@iro.umontreal.ca>

	* icomplete.el (icomplete-show-matches-on-no-input): Default to nil
	(bug#16251).

	* electric.el: Move all electric-pair-* to elec-pair.el.
	* elec-pair.el: New file, split from electric.el.

When I edit stuff, I usually change a function, hit `C-x 4 a' (well, I
have that bound to `Hyper-a'), type in what I did, then perhaps change
the caller, and `C-x 4 a' again, and write what I did there.

Then I commit what I've done.

When I'm programming without a ChangeLog, I edit the first function,
edit the second function, and then commit, writing a summary of what I
did, but I don't mention the function names affected, for instance.

So there's no way to reconstruct a full ChangeLog entry from a normal
commit message, unless we make a `C-x 4 a' equivalent that works without
an actual ChangeLog file.

A temporary ChangeLog file?  A temporary ChangeLog "vc check in" buffer?

A different question is whether this style of change tracking is
valuable or not...

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

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

[Thierry Volpiatto]

Bastien <bzg@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Our ChangeLog files are very useful in debugging.
>> They complement the diffs between versions of the source files.
>
> I think everyone agrees with this.

No, I still think changelog files are unuseful when using a decent dVCS.
With git you have "git-log --grep" and "git-grep" and even
"git-log -p --grep", and "git-log" is also just _working_.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

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

[Bastien]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> No, I still think changelog files are unuseful when using a decent dVCS.
> With git you have "git-log --grep" and "git-grep" and even
> "git-log -p --grep", and "git-log" is also just _working_.

This is for developers.

It's nice for advanced Emacs users to be able to read Changelog
files and check when a new command has been introduced.  If we
require users to know how to use Git for this, the audience shrinks.

My point about keeping Changelogs is that they a useful read for
advanced users *and* for developers who want to know how to format a
correct commit message.

I spend *a lot* of time educating Org's contributors on how to write
a correct commit message.  If we had a Changelog directly in Org, I'd
spend less time, because occasional contributors would immediately
spot those tiny conventions.

-- 
 Bastien

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

[David Kastrup]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> Our ChangeLog files are very useful in debugging.
>>> They complement the diffs between versions of the source files.
>>
>> I think everyone agrees with this.
>
> No, I still think changelog files are unuseful when using a decent dVCS.
> With git you have "git-log --grep" and "git-grep" and even
> "git-log -p --grep", and "git-log" is also just _working_.

I actually use git repositories for working with Subversion based
projects, and obviously also for working with Bazaar based projects.
The first thing I do is checking out a Git mirror or running the (often
expensive) import from Subversion.

And the most important reason for that is not the workflow for
_creating_ new patches (though being able to privately rebase is good),
but for navigating the history of a project and searching its
information.

This is so much more workable than using the _native_ tools of the
respective repositories that it isn't funny.

Now the one thing that will _always_ cause trouble when creating/vetting
a contribution for Emacs is the ChangeLog.  Since Emacs is a reasonably
fast-moving project and the ChangeLog is a central contention point like
the Windows registry, you will _always_ get ChangeLog merge conflicts
when committing.

Now as long as the "native" repository of Emacs is Bazaar with its
absurdly slow log generation, discussing the usefulness or uselessness
of ChangeLog for daily work independently from Git migration seems
pointless: the pros and cons cannot really be estimated by people not
yet using Git.

I'm quite convinced that nobody will miss ChangeLog files when working
with Git.  It's not even a tradeoff.  In my book, that's one of the most
important advantages of Git, but of course it is a hen-and-egg problem
to convince people of that when their current experience tells them a
ChangeLog file can be useful in the course of daily work.

-- 
David Kastrup

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

[Bastien]

David Kastrup <dak@gnu.org> writes:

> I'm quite convinced that nobody will miss ChangeLog files when working
> with Git.

Users?  Especially those who use Emacs from a preinstalled version,
not from a Git clone.

-- 
 Bastien

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

[David Kastrup]

Bastien <bzg@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I'm quite convinced that nobody will miss ChangeLog files when working
>> with Git.
>
> Users?

What about "when working with Git" did you not understand?

> Especially those who use Emacs from a preinstalled version, not from a
> Git clone.

So?  You can generate a ChangeLog file from Git, and we likely would do
so.  But frankly: it is quite unlikely for users to look at a ChangeLog
file.  What's interesting for users is NEWS.  For anything beyond that,
you'll likely just clone the git repository as it is

a) cheap to do (we are not talking about Bazaar here)
b) so much more convenient to search.

-- 
David Kastrup

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

[Bastien]

David Kastrup <dak@gnu.org> writes:

> Bastien <bzg@gnu.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> I'm quite convinced that nobody will miss ChangeLog files when working
>>> with Git.
>>
>> Users?
>
> What about "when working with Git" did you not understand?

I'm not a native english speaker, I may have misunderstood.

I've read the sentence above as "I'm quite convinced that nobody will
miss ChangeLog files whenever we will be working with Git" -- which I
disagree with.

>> Especially those who use Emacs from a preinstalled version, not from a
>> Git clone.
>
> So?  You can generate a ChangeLog file from Git, and we likely would do
> so.  But frankly: it is quite unlikely for users to look at a ChangeLog
> file.  

I did so when I was just a user.  But sure, that's probably a minority.

> What's interesting for users is NEWS.  For anything beyond that,
> you'll likely just clone the git repository as it is
>
> a) cheap to do (we are not talking about Bazaar here)
> b) so much more convenient to search.

I don't see anything to gain in preventing mere users from reading
ChangeLog files, and I see nothing to lose in editing Changelogs that
you copy into commit messages.  It does not even take more time thanks
to C-x v v inserting Changelogs in commit messages directly.

-- 
 Bastien

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

[Per Starbäck]

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

>
> > So?  You can generate a ChangeLog file from Git, and we likely would do
> > so.  But frankly: it is quite unlikely for users to look at a ChangeLog
> > file.
>
> I did so when I was just a user.  But sure, that's probably a minority.
>
>
I do that as well.

Also, there is a point about credit that I don't think has been made: Even
though I don't have write access to the Emacs repository I'm mentioned in
some Changelogs because of fixes I've mailed when reporting bugs. I think I
was somewhat thrilled the first times developers put my name there instead
of their own when checking in those fixes. It is maybe not a big point, but
still a point, since that feeling can be an impetus to making more fixes.

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

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

[David Kastrup]

Per Starbäck <per@starback.se> writes:

>>
>> > So?  You can generate a ChangeLog file from Git, and we likely would do
>> > so.  But frankly: it is quite unlikely for users to look at a ChangeLog
>> > file.
>>
>> I did so when I was just a user.  But sure, that's probably a minority.
>>
>>
> I do that as well.
>
> Also, there is a point about credit that I don't think has been made:
> Even though I don't have write access to the Emacs repository I'm
> mentioned in some Changelogs because of fixes I've mailed when
> reporting bugs. I think I was somewhat thrilled the first times
> developers put my name there instead of their own when checking in
> those fixes. It is maybe not a big point, but still a point, since
> that feeling can be an impetus to making more fixes.

So what?  If you send in a patch formatted with git format-patch, you
will be listed the author of the patch automatically when the patch is
applied with git am, regardless of who pushes it (the pusher of a patch
is only a minor information you have to ask explicitly for: the normal
log does not mention him or her, the main information being the author
of a patch).

Even if you send in just a diff, it can be committed using the --author
option in order to preserve proper credit.

So your "point about credit" is not more than a misconception.

-- 
David Kastrup

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

[Glenn Morris]

Per Starbäck wrote:

> Also, there is a point about credit that I don't think has been made: Even
> though I don't have write access to the Emacs repository I'm mentioned in
> some Changelogs because of fixes I've mailed when reporting bugs. I think I
> was somewhat thrilled the first times developers put my name there instead
> of their own when checking in those fixes. It is maybe not a big point, but
> still a point, since that feeling can be an impetus to making more fixes.

That's why we encourage use of --author when committing things by other
people.

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

[Achim Gratz]

Bastien writes:
> Richard Stallman <rms@gnu.org> writes:
>> Our ChangeLog files are very useful in debugging.
>> They complement the diffs between versions of the source files.
>
> I think everyone agrees with this.

FWIW, I don't.  I've used ChangeLogs and Journals while I was still
using RCS and I'm glad I don't have to anymore.  With properly written
commit messages, I get more easily accessible and much more accurate
information than by just looking at a ChangeLog or trying to align
ChangeLog entries with a diff.

> The question is whether we should edit them separately
> from the commit messages, or if we should produce them
> by (programmatically) extracting them from the commit
> messages.

If the information in the commit message and the ChangeLog is different
to begin with, then you're doing something wrong.  If it is (supposed to
be) identical, then manually entering the same information in two
different places is unnecessarily complex and error-prone, so generating
one format from the other is the only sane option.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 2:07 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> With properly written
> commit messages

And how will we get that? Something as obvious as making the first
line a summary so it shows correctly in --line logs has been suggested
(repeatedly) in the past, and yet it's often ignored, even by some
highly experienced developers.

Generating ChangeLogs from commit messages will be easier and faster
that what we do now, but I'm willing to bet a few euros it will give
us *much* worse ChangeLogs.

    J

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

[Jarek Czekalski]

W dniu 01/04/2014 09:03 PM, Juanma Barranquero pisze:
> (...) Something as obvious as making the first
> line a summary so it shows correctly in --line logs has been suggested
> (repeatedly) in the past, and yet it's often ignored, even by some
> highly experienced developers.

You will have to repeat it many times more if you don't put it in the 
right place, which is
http://www.emacswiki.org/emacs/BzrForEmacsDevs

Jarek

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

[Achim Gratz]

Juanma Barranquero writes:
>> With properly written commit messages
>
> And how will we get that?

Where do the ChangeLog entries come from today, then?

> Something as obvious as making the first line a summary so it shows
> correctly in --line logs has been suggested (repeatedly) in the past,
> and yet it's often ignored, even by some highly experienced
> developers.

There are various ways to prevent such commits wending their way into
the official repo and there are also ways to add fixes if necessary.
These would perhaps trigger workflow changes that have little if
anything to do with Git, although it might be a good time to discuss
them before switching from Bzr.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 9:37 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> Where do the ChangeLog entries come from today, then?

People write them, obviously. Somehow, many people seem more careful
when writing the ChangeLog than doing the same in the commit log
buffer or the commit command in the command line.

Also, many ChangeLog entries are fixed or reworded afterwards (and I'm
not talking about obvious typos and whitespace, but duplicates,
factual errors, etc.). You can not fix a commit log message.

   J

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

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 4 Jan 2014 21:53:14 +0100
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> You can not fix a commit log message.

If git is supported as well as we are told, perhaps the git developers
can be asked to add a feature that will allow commit messages to be
fixed, at least as far as the output of "git log" etc. is concerned.
CVS allowed such changes, btw.

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

[Juanma Barranquero]

On Sat, Jan 4, 2014 at 10:13 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> If git is supported as well as we are told, perhaps the git developers
> can be asked to add a feature that will allow commit messages to be
> fixed, at least as far as the output of "git log" etc. is concerned.

There's notes (git notes etc.). Perhaps it would make sense to use
some commit hook to move the commit log message to a note
automagically... That wouldn't be ideal, but it would go a long way to
make losing the ChangeLogs palatable.

    J

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

[Nathan Trapuzzano]

Eli Zaretskii <eliz@gnu.org> writes:

> If git is supported as well as we are told, perhaps the git developers
> can be asked to add a feature that will allow commit messages to be
> fixed, at least as far as the output of "git log" etc. is concerned.
> CVS allowed such changes, btw.

git rebase --interactive

With a source repository like Emacs', which is shared by so many people,
doing that is a terrible idea.

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

[Stefan Monnier]

>> If git is supported as well as we are told, perhaps the git developers
>> can be asked to add a feature that will allow commit messages to be
>> fixed, at least as far as the output of "git log" etc. is concerned.
>> CVS allowed such changes, btw.
> git rebase --interactive
> With a source repository like Emacs', which is shared by so many people,
> doing that is a terrible idea.

Right: by "edit past commit messages" we mean "without rewriting
history".  I know it sounds contradictory, but it is only paradoxical.


        Stefan

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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Right: by "edit past commit messages" we mean "without rewriting
 > history".  I know it sounds contradictory, but it is only paradoxical.

It's neither.  It's an artifact of git implementation.

I'm pretty sure there are VCSes that don't make the commit message
part of history, but I think that's disgusting and don't allow VCSes
like that in my house.

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

[Stefan Monnier]

> be) identical, then manually entering the same information in two
> different places is unnecessarily complex and error-prone, so generating

If you enter it twice, you're not using your tool right.  Emacs can
extract the commit message from the ChangeLog file right before you
commit, so you don't have to enter it twice.

IOW, please guys re-read the corresponding thread from a few years back.
Nothing much has changed.

The main issues were (and are) the following:
- How to edit past commit messages when they're incorrect/incomplete/...?
- How to do C-x 4 a when there's no ChangeLog file?
- This last one can get a bit more delicate if you want to be able to do

     hack..hack..hack
     C-x 4 a
     hack..hack..
     C-x C-c
     restart Emacs
     ...
     commit

  since this requires saving the commit message which you started
  writing in the first Emacs session: the ChangeLog file naturally lives
  across Emacs sessions, whereas the *VC-Log* buffer doesn't.
  

        Stefan

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

[Achim Gratz]

Stefan Monnier writes:
>> be) identical, then manually entering the same information in two
>> different places is unnecessarily complex and error-prone, so generating
>
> If you enter it twice, you're not using your tool right.  Emacs can
> extract the commit message from the ChangeLog file right before you
> commit, so you don't have to enter it twice.

That's exactly what I said in the next line of that sentence which you
didn't quote.  I purposefully avoided the contentious issue of saying
which direction I might prefer.

> The main issues were (and are) the following:
> - How to edit past commit messages when they're
> incorrect/incomplete/...?

Git notes still seems like a good solution.

> - How to do C-x 4 a when there's no ChangeLog file?

You don't need to.  I'm usually writing the commit messages as I stage
the diffs for the upcoming commit.  I also frequently rewrite commits
before pushing them upstream.  Extracting that information from a
ChangeLog to build the commit message is completely backwards with that
kind of workflow and easily leads to typical errors like documenting
changes that aren't actually committed or implemented differently or
additional undocumented changes that might or might not be intended to
be part of the commit.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

[Stefan Monnier]

>> The main issues were (and are) the following:
>> - How to edit past commit messages when they're
>> incorrect/incomplete/...?
> Git notes still seems like a good solution.

AFAIK "git notes" is a low-level tool which clever scripts might be able
to leverage to provide the ability to "edit past commit messages".
I've never seen those clever scripts, tho.

>> - How to do C-x 4 a when there's no ChangeLog file?
> You don't need to.

I do.

> I'm usually writing the commit messages as I stage
> the diffs for the upcoming commit.  I also frequently rewrite commits
> before pushing them upstream.  Extracting that information from a
> ChangeLog to build the commit message is completely backwards with that

C-x 4 a has nothing to do with extracting the message from
the ChangeLog.  I usually use C-x 4 a from the *vc-diff* buffer.


        Stefan

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

[Stephen J. Turnbull]

Stefan Monnier writes:

 > The main issues were (and are) the following:

 > - How to edit past commit messages when they're
 >   incorrect/incomplete/...?

Best solution: no commit without review.  Not gonna happen :-) so,
"git notes".

 > - How to do C-x 4 a when there's no ChangeLog file?

ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog

works for me in private projects.  The commit alias removes
.tmp_commit_log, so I can't commit without writing a commit log
("fatal: could not read log file '.tmp_commit_log': No such file or
directory").

 > - This last one can get a bit more delicate if you want to be able
 >   to do

Yeah, probably it's still a bit delicate.

 >   since this requires saving the commit message which you started
 >   writing in the first Emacs session: the ChangeLog file naturally lives
 >   across Emacs sessions, whereas the *VC-Log* buffer doesn't.

but not for that reason. ;-)  Dunno if that trick works on Windows,
for one.

Steve

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

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 05 Jan 2014 17:34:47 +0900
> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
> 
>  > - How to do C-x 4 a when there's no ChangeLog file?
> 
> ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
> 
> works for me in private projects.

I don't understand why you need the symlink.  Why not let Emacs create
ChangeLog, then delete it when the commit is done?  Or use any other
file name (if you don't want to see ChangeLog for some reason): the
Change Log mode can be turned on in any file, regardless of its name.
For that matter, why not reuse .git/COMMIT_EDITMSG?

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

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Date: Sun, 05 Jan 2014 17:34:47 +0900
 > > Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
 > > 
 > >  > - How to do C-x 4 a when there's no ChangeLog file?
 > > 
 > > ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
 > > 
 > > works for me in private projects.
 > 
 > I don't understand why you need the symlink.  Why not let Emacs create
 > ChangeLog, then delete it when the commit is done?

IIRC, it was as a marker, I only wanted one of them, and didn't feel
like debugging logic to find the project root by other means.

The point in mentioning it here is that there are trivial hacks that
don't require any changes to add-change-log-entry.

 > Or use any other file name (if you don't want to see ChangeLog for
 > some reason): the Change Log mode can be turned on in any file,
 > regardless of its name.

As above, it was important (maybe only to my paranoia) that ChangeLog
be present in the directory but not be a readable file.

 > For that matter, why not reuse .git/COMMIT_EDITMSG?

Caution.  Who knows what else git might be using it for?  Or maybe I
just didn't know that was the name of the editmsg file at that time --
it was a long time ago.

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

[Stefan Monnier]

>> - How to do C-x 4 a when there's no ChangeLog file?
> ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog
> works for me in private projects.  The commit alias removes
> .tmp_commit_log, so I can't commit without writing a commit log
> ("fatal: could not read log file '.tmp_commit_log': No such file or
> directory").

Right, that's the kind of direction I'd like to go.  But this
.tmp_commit_log file seems to be a personal convention, so making `C-x
4 a' use such a thing by default is more difficult.


        Stefan

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

[Stephen J. Turnbull]

Stefan Monnier writes:
 > >> - How to do C-x 4 a when there's no ChangeLog file?
 > > ln -s $PROJECT_ROOT/.tmp_commit_log $PROJECT_ROOT/ChangeLog

 > Right, that's the kind of direction I'd like to go.  But this
 > .tmp_commit_log file seems to be a personal convention, so making `C-x
 > 4 a' use such a thing by default is more difficult.

C-x 4 a doesn't know about .tmp_commit_log, that's the point of the
symlink.  It just does what it always does.

I don't see why this can't be a project convention, perhaps using
.git/GIT_EDITMSG as Eli suggests.

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

[Stefan Monnier]

> I don't see why this can't be a project convention, perhaps using
> .git/GIT_EDITMSG as Eli suggests.

I'd like Emacs to support it for all projects.


        Stefan

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

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > I don't see why this can't be a project convention, perhaps using
 > > .git/GIT_EDITMSG as Eli suggests.
 > 
 > I'd like Emacs to support it for all projects.

And?  I don't see a problem:

  (setq vc-message-file (format (vc-message-file-fmt vc-backend)
                                project-root))

with the "obvious" (== I'm in a hurry, ask me if not) semantics for
`vc-message-file' and `vc-message-file-fmt' (and don't shoot me if
there are obviously better ways to implement it in vc.el or
add-log.el, just do it! ;-)

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

[Stefan Monnier]

>> > I don't see why this can't be a project convention, perhaps using
>> > .git/GIT_EDITMSG as Eli suggests.
>> I'd like Emacs to support it for all projects.
> And?  I don't see a problem:
>   (setq vc-message-file (format (vc-message-file-fmt vc-backend)
>                                 project-root))
> with the "obvious" (== I'm in a hurry, ask me if not) semantics for
> `vc-message-file' and `vc-message-file-fmt' (and don't shoot me if
> there are obviously better ways to implement it in vc.el or
> add-log.el, just do it! ;-)

That's the idea, yes.  But then you want to make sure the file is
ignored by the VCS; that it gets erased after commit, and things
like that.

Also, you'd probably want to "unify" that file and *VC-Log*, which
brings in more details with which to deal.

I'm not saying it's fundamentally necessarily hard.  But someone has to
write the code, and deal with the problems that can show up.


        Stefan

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

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

    The question is whether we should edit them separately
    from the commit messages, or if we should produce them
    by (programmatically) extracting them from the commit
    messages.

I think it is best for commit messages to be brief high-level 
summaries of the changes, and put the details only in ChangeLog.
I think that these two forms of desription complement each other
and that it is useful to have both available.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>     The question is whether we should edit them separately
>     from the commit messages, or if we should produce them
>     by (programmatically) extracting them from the commit
>     messages.
>
> I think it is best for commit messages to be brief high-level 
> summaries of the changes, and put the details only in ChangeLog.
> I think that these two forms of desription complement each other
> and that it is useful to have both available.

Git treats the first line of a commit message specifically as a summary.
When formatting a commit for mailing, this line is used as the subject
of the mail while the rest of the commit message appears in the mail
body.

This inherent subdivision of commit messages maps well enough to the GNU
subdivision of complementing summary/detail that it becomes mostly
pointless in practice to maintain a separate file for storing this
information.

-- 
David Kastrup

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

[Glenn Morris]

David Kastrup wrote:

> Git treats the first line of a commit message specifically as a summary.
> When formatting a commit for mailing, this line is used as the subject
> of the mail

That would be nice. Please fix the emacs-elpa-diffs list accordingly:

http://lists.gnu.org/archive/html/emacs-elpa-diffs/2013-12/index.html

Because currently I find it less useful than it was under bzr.

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

[Stefan Monnier]

>> Git treats the first line of a commit message specifically as a summary.
>> When formatting a commit for mailing, this line is used as the subject
>> of the mail
> That would be nice. Please fix the emacs-elpa-diffs list accordingly:
> http://lists.gnu.org/archive/html/emacs-elpa-diffs/2013-12/index.html

Yes, please.

> Because currently I find it less useful than it was under bzr.

Quite!


        Stefan

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

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think it is best for commit messages to be brief high-level 
 > summaries of the changes, and put the details only in ChangeLog.

This violates the "don't repeat yourself" principle to some extent,
and conflicts with habits formed in other projects.  Some projects
don't have ChangeLogs (or don't bother about commit messages, but
that's very rare), so the preferred format gets all data, usually with
some convention about a single line that *identifies* the commit, but
may not be a full "executive summary".  (For those who know Darcs,
think "patch name".)

I also get the feeling that a lot of committers feel that they receive
ambiguous, even conflicting, advice about commit message and ChangeLog
entries (eg, "follow the GNU Coding Standard" vs. "here's how you
should do it" if Florian's characterization is correct).

 > I think that these two forms of desription complement each other
 > and that it is useful to have both available.

There's absolutely no reason why both can't be in a single "place".
The implementation in commit messages could be done via a VCS feature
like "git notes" (resp, a special log formatter -- Jordi says
Mercurial has a whole template language that can be used in logs), so
you don't see the detail unless you ask for notes (resp, the verbose
form).  It could be done via a log-viewer Emacs mode.

But as Eric says, this is not the thread to discuss that, because it
changes workflow.

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

[Bastien]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>     The question is whether we should edit them separately
>     from the commit messages, or if we should produce them
>     by (programmatically) extracting them from the commit
>     messages.
>
> I think it is best for commit messages to be brief high-level 
> summaries of the changes, and put the details only in ChangeLog.
> I think that these two forms of desription complement each other
> and that it is useful to have both available.

FWIW, I fully agree.

-- 
 Bastien

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> Our ChangeLog files are very useful in debugging.
> They complement the diffs between versions of the source files.

So do commit messages.  What makes Git commit messages eternally more
useful in practice is the versatility: I can _immediately_ view just the
messages pertaining to a subdirectory, or a file, or a branch (without
checking it out), and when I use the --grep option, I get the matching
commit messages in full rather than a -3 style context when using grep
on a ChangeLog file.  And even when I want to search for a flat text in
the single ChangeLog of the top directory, the best use case for a
ChangeLog file, this is less convenient the moment a ChangeLog file has
to be split.

And git log is reliable.  When I ask Git for all commit messages
touching a certain file, it will not miss changes.  It will, when I
want, give the respective diffs (-p option) along with the commit
messages, or just a list of changed files (--stat).

-- 
David Kastrup

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

[Florian Weimer]

* Richard Stallman:

> Our ChangeLog files are very useful in debugging.

Then you're not following the GNU Coding Standards. :-)

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

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

    > Our ChangeLog files are very useful in debugging.

    Then you're not following the GNU Coding Standards. :-)

There is no constructive point there, only an insult.

If you have some constructive criticism, please state it clearly.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Florian Weimer]

* Richard Stallman:

>     > Our ChangeLog files are very useful in debugging.
>
>     Then you're not following the GNU Coding Standards. :-)
>
> There is no constructive point there, only an insult.

It was not intended as such, I'm sorry if it came across this way.

> If you have some constructive criticism, please state it clearly.

In particular, this advice does not make much sense to me:

| For changes to code, there’s no need to describe the full purpose of
| the changes or how they work together. If you think that a change
| calls for explanation, you’re probably right. Please do explain it—but
| please put the full explanation in comments in the code, where people
| will see it whenever they see the code. For example, “New function” is
| enough for the change log when you add a function, because there
| should be a comment before the function definition to explain what it
| does.

<http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html>

I find this pretty strange because adding comments typically does not
make sense when one removes code (which sometimes needs *more*
explanation than adding code).  And when rearranging code, there is
often no single place to put a comment *why* this was done.

I never consult changelog files if I have the full VCS history.  In my
experience, grepping diffs, annotate/blame, or bisecting is more
helpful (assuming that I have a hunch history provides an explanation)
because the raw bits are usually less misleading, and the changelog
files are often deliberately devoid of any additional information.
The lisp/ changelog seems to deviate from this a bit, but there are
other GNU projects where the changelog rules are enforced through
review.

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

[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 find this pretty strange because adding comments typically does not
    make sense when one removes code (which sometimes needs *more*
    explanation than adding code).  And when rearranging code, there is
    often no single place to put a comment *why* this was done.

I find there is generally some place in the source file where
the explanation belongs.  It can be in some related place in the code,
someplace where people will see it when it is relevant.

But why not put it in ChangeLog?  It wouldn't be horrible to put it
there, from time to time.  But preferably not often.

One ChangeLog file covers many source files, and if we generally put
the explanations in ChangeLog, it would become cumbersome.  So it is
better to put those explanations in the source code.

Also, most often an explanation is directly relevant to existing code,
and the best way to make sure people see it is to put it there.

    I never consult changelog files if I have the full VCS history.

I do.  I use the ChangeLog files to see what changes affected
a certain function.  Then I use VC history to look at the changes
that are relevant to the issue.

-- 
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: PROPOSAL: Move to git, now that bzr is no longer a req.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I never consult changelog files if I have the full VCS history.
>
> I do.  I use the ChangeLog files to see what changes affected a
> certain function.

I tend to use C-x v g for that (it maps to git blame).  Its drawback is
that it also reflects whitespace changes, but then it's easy to navigate
across them with the proper keybindings (usually A) until finding the
change one is looking for, then getting the corresponding log with l.

> Then I use VC history to look at the changes that are relevant to the
> issue.

I'm not saying that this is an "invalid" workflow.  However, the generic
VC support of Emacs allows, when coupled with a version control system
that is reasonably fast, to use alternate workflows that do not suffer
from significant drawbacks compared to the benefits from not having to
maintain manual ChangeLog files separately.

This is not specific to Git (actually, it was already available in CVS).
What is noticeable, however, is that Git's performance does not make
this a waiting game, and that Git is often able to track the origin of
lines even when material was rearranged beyond the renaming of files.

Git offers several options for the amount of history searching it should
perform: what is intransparent is just which options vc.el happens to be
using and how one can change them in case something goes wrong.

In general, it's more often than not the case that Git finds out more
than one expected, but when the reverse happens, vc-git does not make it
easily discoverable how one can tell Git to search more thoroughly.

I digress: what I wanted to say is that one gets a few tools (and with
an Emacs interface) that work reasonably well for addressing most of the
tasks one would otherwise use a ChangeLog to get done.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 06 Jan 2014 15:53:28 +0100
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >     I never consult changelog files if I have the full VCS history.
> >
> > I do.  I use the ChangeLog files to see what changes affected a
> > certain function.
> 
> I tend to use C-x v g for that (it maps to git blame).

This can be annoyingly slow (and with git is slower than with bzr).
E.g., try xdisp.c: it takes git more than 4 minutes to display
anything in response to "C-x v g" (2 minutes if done from the shell).
Looking into ChangeLog's is surely faster.

Someone, I think it was you, once told me that the slow operation of
'git blame' was a deliberate design decision of the git developers.
So it doesn't sound like this is supposed to be the first tool to be
used for such jobs.  FWIW, I use that only after I already have some
idea about what I'm looking for and in which time period.

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

[Jordi Gutiérrez Hermoso]

On Mon, 2014-01-06 at 18:09 +0200, Eli Zaretskii wrote:

> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the
> shell). Looking into ChangeLog's is surely faster.

As a point of comparsion, on my system

    $ time hg blame xdisp.c > foo

    real  0m55.426s
    user  0m54.083s
    sys   0m1.032s

    $ time git blame xdisp.c > foo

    real  3m24.979s
    user  3m5.920s
    sys   0m3.032s

I suppose this is because git's data structures aren't very fast for
single-file operations. The only way to get data for a single file in
git is to walk the entire changelog and grab all associated tree
objects looking for the blob you care about. Hg's data structures
instead, changes across a single file using a so-called revlog, which
is a series per-file deltas with occasional full file copies (the
analogy for revlogs is video compression with key frames).

- Jordi G. H.

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

[Eli Zaretskii]

> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 06 Jan 2014 12:57:49 -0500
> 
> On Mon, 2014-01-06 at 18:09 +0200, Eli Zaretskii wrote:
> 
> > E.g., try xdisp.c: it takes git more than 4 minutes to display
> > anything in response to "C-x v g" (2 minutes if done from the
> > shell). Looking into ChangeLog's is surely faster.
> 
> As a point of comparsion, on my system
> 
>     $ time hg blame xdisp.c > foo
> 
>     real  0m55.426s
>     user  0m54.083s
>     sys   0m1.032s
> 
>     $ time git blame xdisp.c > foo
> 
>     real  3m24.979s
>     user  3m5.920s
>     sys   0m3.032s

I don't see any point in these comparisons (having been there before),
but since you started...

  D:\gnu\bzr\emacs\trunk>timep bzr annotate src/xdisp.c > foo
  real    00h00m29.265s
  user    00h00m26.578s
  sys     00h00m00.843s

  $ time git blame src/xdisp.c > foo
  real    2m5.281s
  user    0m0.015s
  sys     0m0.000s

(This is on Windows, so in the case of git, the user and system times
are bogus, because Windows provides no means of accounting for
grandchildren subprocesses.)

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 06 Jan 2014 15:53:28 +0100
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >     I never consult changelog files if I have the full VCS history.
>> >
>> > I do.  I use the ChangeLog files to see what changes affected a
>> > certain function.
>> 
>> I tend to use C-x v g for that (it maps to git blame).
>
> This can be annoyingly slow (and with git is slower than with bzr).
> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the shell).

Oh wow.  Impressive.  Not my average experience, but certainly a
sobering outlier.

> Someone, I think it was you, once told me that the slow operation of
> 'git blame' was a deliberate design decision of the git developers.

Yes and no.  The information is reconstructed rather than stored, but in
general the information is reconstructed rather fast.

git blame also has an incremental mode.  For cases such like this, it
might make sense trying to find a way to integrate this into the
operation of C-x v g though I have to admit that I am somewhat at a loss
regarding how to do this in a pleasant way.

> So it doesn't sound like this is supposed to be the first tool to be
> used for such jobs.  FWIW, I use that only after I already have some
> idea about what I'm looking for and in which time period.

In general, it works pretty well for me.  I have to admit that xdisp.c
is convincingly bad in that regard.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 06 Jan 2014 19:07:02 +0100
> 
> I have to admit that xdisp.c is convincingly bad in that regard.

Well, it's a monster file which gets a lot of changes, so it's
definitely not the average.

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

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Mon, 06 Jan 2014 15:53:28 +0100
>> 
>> Richard Stallman <rms@gnu.org> writes:
>> 
>> >     I never consult changelog files if I have the full VCS history.
>> >
>> > I do.  I use the ChangeLog files to see what changes affected a
>> > certain function.
>> 
>> I tend to use C-x v g for that (it maps to git blame).
>
> This can be annoyingly slow (and with git is slower than with bzr).
> E.g., try xdisp.c: it takes git more than 4 minutes to display
> anything in response to "C-x v g" (2 minutes if done from the shell).
> Looking into ChangeLog's is surely faster.
>
> Someone, I think it was you, once told me that the slow operation of
> 'git blame' was a deliberate design decision of the git developers.

No, not really: it's just that blaming a file is not cheaper than
blaming a directory.

At any rate, I'm currently just analyzing the code for git-blame, and
for better or worse, it's appallingly bad (quadratic in file size, times
number of commits).  It should be fairly straightforward to bring down
the time rather dramatically.  Several inner loops are run more than
2^32 times for "git blame src/xdisp.c".

It's not a design decision, it is just bad programming.  Salvageable.
Considering how much life time I spent waiting for some git-gui blame (I
conveniently forgot about that, I have to admit) it's sort of amusing
that I never thought of looking at its code (several years ago,
I improved some of the performance-critical but already efficient parts
of git).  This should be rather low-hanging fruit.

Of course, it will likely take a year to trickle down even if I
contribute something in the next weeks.

-- 
David Kastrup

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

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Tue, 07 Jan 2014 20:17:15 +0100
> 
> At any rate, I'm currently just analyzing the code for git-blame, and
> for better or worse, it's appallingly bad (quadratic in file size, times
> number of commits).  It should be fairly straightforward to bring down
> the time rather dramatically.  Several inner loops are run more than
> 2^32 times for "git blame src/xdisp.c".
> 
> It's not a design decision, it is just bad programming.  Salvageable.
> Considering how much life time I spent waiting for some git-gui blame (I
> conveniently forgot about that, I have to admit) it's sort of amusing
> that I never thought of looking at its code (several years ago,
> I improved some of the performance-critical but already efficient parts
> of git).  This should be rather low-hanging fruit.

It would be nice, as for me xdisp.c is a file into whose history I
must dig very frequently.

Thanks.

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

[Rüdiger Sonderfeld]

On Tuesday 07 January 2014 20:17:15 David Kastrup wrote:
> It's not a design decision, it is just bad programming.  Salvageable.
> Considering how much life time I spent waiting for some git-gui blame (I
> conveniently forgot about that, I have to admit) it's sort of amusing
> that I never thought of looking at its code (several years ago,
> I improved some of the performance-critical but already efficient parts
> of git).  This should be rather low-hanging fruit.
> 
> Of course, it will likely take a year to trickle down even if I
> contribute something in the next weeks.

Please fix this.  Running git blame on a large file is quite a pain 
(especially when done through `magit-blame-mode' or other synchronous emacs 
blame mode).

Regards
Rüdiger

Re: bzr is dying; Emacs needs to move

[Eric S. Raymond]

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

Thank you.

And yes, it was.  It wouldn't have been my choice, but it was
light-years better than CVS and a clear improvement over any
possibility other than hg or git.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: bzr is dying; Emacs needs to move

[Sam Steingold]

> * Eric S. Raymond <rfe@gulefhf.pbz> [2014-01-02 04:53:47 -0500]:
>
> git won the mindshare war.  I regret this - I would have preferred
> Mercurial, but it too is not looking real healthy these days.

I too prefer Mercurial.

What is your basis for asserting its ill health?
(this is a genuine request for information, all I know is that hg wins
against git in googlefight: http://www.googlefight.com/index.php?word1=hg&word2=git)

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1265
http://www.childpsy.net/ http://mideasttruth.com http://dhimmi.com
http://think-israel.org http://truepeace.org http://memri.org
My inferiority complex is not as good as yours.

Re: bzr is dying; Emacs needs to move

[Samuel El-Borai]

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

2014/1/2 Sam Steingold <sds@gnu.org>
>
> (this is a genuine request for information, all I know is that hg wins
> against git in googlefight:
> http://www.googlefight.com/index.php?word1=hg&word2=git)


That's not really true
http://www.googlefight.com/index.php?lang=en_GB&word1=hg+dvcs&word2=git+dvcs

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

Re: bzr is dying; Emacs needs to move

[David Reitter]

In support of the proposal:

1. Yes, please switch to git.

2. I am someone who had commit access in CVS days, but stopped making my small contributions when bzr was introduced, following extensive tries to adopt bzr for Aquamacs or to use it for small, infrequent contributions.  It didn't seem worth the effort.

3. Please use the official mirror as a basis.  It's a good mirror.  Anything else would be a PITA for downstream developers and anyone who maintains a separate git branch of Emacs.   After 50 merges from the mainline and >4500 commits, rebasing to preserve history seems like a big deal.

4. The Changelog files are a frequent cause of conflicts.  "git log --grep=" is fast.  What is the use?


On Jan 2, 2014, at 4:53 AM, Eric S. Raymond <esr@thyrsus.com> wrote:

> 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: PROPOSAL: Move to git, now that bzr is no longer a req.

[Ting-Yu Lin (林庭宇)]

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

+1 for git.

BTW, it is more pleasant to use git in Emacs with
magit<https://github.com/magit/magit>
.

Tingy-Yu

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