* Re: Apologia for bzr @ 2014-01-07 9:32 Alexander Meesters 0 siblings, 0 replies; 123+ messages in thread From: Alexander Meesters @ 2014-01-07 9:32 UTC (permalink / raw) To: emacs-devel Dear Dr. Stallman, To answer your question:"Do beginners typically run Emacs under a graphical window system?", it seems so. I myself am a recent Emacs adaptee(its been 3 days now), since i finaly decided to learn to program in C(comming from a php and python background). From what i picked up on the several IRC chatrooms i visit, the generally use is under a graphical window system, although this would be hardly representable for the masses, i didnt even know Emacs can work without a GUI, most "Getting started with Emacs" tutorial that are scattered throughout the web only cover the Emacs GUI. Sincerely, Alexander "Cyberwaste" Meesters. PS) thank you for all the beautifull things you have given us. ^ permalink raw reply [flat|nested] 123+ messages in thread
* bzr is dying; Emacs needs to move @ 2014-01-02 9:53 Eric S. Raymond 2014-01-02 15:04 ` Richard Stallman 0 siblings, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-02 9:53 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: bzr is dying; Emacs needs to move 2014-01-02 9:53 bzr is dying; Emacs needs to move Eric S. Raymond @ 2014-01-02 15:04 ` Richard Stallman 2014-01-02 15:41 ` PROPOSAL: Move to git, now that bzr is no longer a req Karl Fogel 0 siblings, 1 reply; 123+ messages in thread From: Richard Stallman @ 2014-01-02 15:04 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* PROPOSAL: Move to git, now that bzr is no longer a req. 2014-01-02 15:04 ` Richard Stallman @ 2014-01-02 15:41 ` Karl Fogel 2014-01-02 17:10 ` Eli Zaretskii 0 siblings, 1 reply; 123+ messages in thread From: Karl Fogel @ 2014-01-02 15:41 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: PROPOSAL: Move to git, now that bzr is no longer a req. 2014-01-02 15:41 ` PROPOSAL: Move to git, now that bzr is no longer a req Karl Fogel @ 2014-01-02 17:10 ` Eli Zaretskii 2014-01-02 17:28 ` Eric S. Raymond 0 siblings, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-02 17:10 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: PROPOSAL: Move to git, now that bzr is no longer a req. 2014-01-02 17:10 ` Eli Zaretskii @ 2014-01-02 17:28 ` Eric S. Raymond 2014-01-02 17:56 ` Eli Zaretskii 0 siblings, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-02 17:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Karl Fogel, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: PROPOSAL: Move to git, now that bzr is no longer a req. 2014-01-02 17:28 ` Eric S. Raymond @ 2014-01-02 17:56 ` Eli Zaretskii 2014-01-02 18:34 ` Apologia for bzr Eric S. Raymond 0 siblings, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-02 17:56 UTC (permalink / raw) To: esr; +Cc: kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Apologia for bzr 2014-01-02 17:56 ` Eli Zaretskii @ 2014-01-02 18:34 ` Eric S. Raymond 2014-01-02 20:44 ` Eli Zaretskii 0 siblings, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-02 18:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 18:34 ` Apologia for bzr Eric S. Raymond @ 2014-01-02 20:44 ` Eli Zaretskii 2014-01-02 20:51 ` Eric S. Raymond ` (2 more replies) 0 siblings, 3 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-02 20:44 UTC (permalink / raw) To: esr; +Cc: kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 20:44 ` Eli Zaretskii @ 2014-01-02 20:51 ` Eric S. Raymond 2014-01-02 21:03 ` Eli Zaretskii 2014-01-02 21:14 ` Toby Cubitt 2014-01-03 9:44 ` Tassilo Horn 2 siblings, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-02 20:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: kfogel, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 20:51 ` Eric S. Raymond @ 2014-01-02 21:03 ` Eli Zaretskii 2014-01-02 21:15 ` Juanma Barranquero 2014-01-02 21:31 ` Óscar Fuentes 0 siblings, 2 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-02 21:03 UTC (permalink / raw) To: esr; +Cc: kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 21:03 ` Eli Zaretskii @ 2014-01-02 21:15 ` Juanma Barranquero 2014-01-03 7:47 ` Eli Zaretskii 2014-01-02 21:31 ` Óscar Fuentes 1 sibling, 1 reply; 123+ messages in thread From: Juanma Barranquero @ 2014-01-02 21:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Raymond, Karl Fogel, Emacs developers 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 21:15 ` Juanma Barranquero @ 2014-01-03 7:47 ` Eli Zaretskii 2014-01-03 11:11 ` Juanma Barranquero 0 siblings, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 7:47 UTC (permalink / raw) To: Juanma Barranquero; +Cc: esr, kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 7:47 ` Eli Zaretskii @ 2014-01-03 11:11 ` Juanma Barranquero 2014-01-03 11:46 ` Eli Zaretskii 0 siblings, 1 reply; 123+ messages in thread From: Juanma Barranquero @ 2014-01-03 11:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Raymond, Karl Fogel, Emacs developers 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 11:11 ` Juanma Barranquero @ 2014-01-03 11:46 ` Eli Zaretskii 2014-01-03 11:55 ` Juanma Barranquero 0 siblings, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 11:46 UTC (permalink / raw) To: Juanma Barranquero; +Cc: esr, kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 11:46 ` Eli Zaretskii @ 2014-01-03 11:55 ` Juanma Barranquero 0 siblings, 0 replies; 123+ messages in thread From: Juanma Barranquero @ 2014-01-03 11:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Raymond, Karl Fogel, Emacs developers 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 21:03 ` Eli Zaretskii 2014-01-02 21:15 ` Juanma Barranquero @ 2014-01-02 21:31 ` Óscar Fuentes 1 sibling, 0 replies; 123+ messages in thread From: Óscar Fuentes @ 2014-01-02 21:31 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 20:44 ` Eli Zaretskii 2014-01-02 20:51 ` Eric S. Raymond @ 2014-01-02 21:14 ` Toby Cubitt 2014-01-03 8:57 ` Eli Zaretskii 2014-01-03 14:37 ` Richard Stallman 2014-01-03 9:44 ` Tassilo Horn 2 siblings, 2 replies; 123+ messages in thread From: Toby Cubitt @ 2014-01-02 21:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 21:14 ` Toby Cubitt @ 2014-01-03 8:57 ` Eli Zaretskii 2014-01-03 9:21 ` Yuri Khan 2014-01-03 20:34 ` Stephen J. Turnbull 2014-01-03 14:37 ` Richard Stallman 1 sibling, 2 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 8:57 UTC (permalink / raw) To: Toby Cubitt; +Cc: esr, kfogel, emacs-devel > 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 ;-) ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 8:57 ` Eli Zaretskii @ 2014-01-03 9:21 ` Yuri Khan 2014-01-03 10:08 ` Eli Zaretskii 2014-01-03 20:34 ` Stephen J. Turnbull 1 sibling, 1 reply; 123+ messages in thread From: Yuri Khan @ 2014-01-03 9:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Eric Raymond, kfogel, Toby Cubitt, Emacs developers 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 9:21 ` Yuri Khan @ 2014-01-03 10:08 ` Eli Zaretskii 0 siblings, 0 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 10:08 UTC (permalink / raw) To: Yuri Khan; +Cc: esr, kfogel, toby-dated-1389906911.cc0ede, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 8:57 ` Eli Zaretskii 2014-01-03 9:21 ` Yuri Khan @ 2014-01-03 20:34 ` Stephen J. Turnbull 2014-01-03 21:07 ` Eli Zaretskii 2020-10-29 7:11 ` Drew Adams 1 sibling, 2 replies; 123+ messages in thread From: Stephen J. Turnbull @ 2014-01-03 20:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, Toby Cubitt, emacs-devel 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! ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:34 ` Stephen J. Turnbull @ 2014-01-03 21:07 ` Eli Zaretskii 2014-01-04 5:01 ` Stephen J. Turnbull 2020-10-29 7:11 ` Drew Adams 1 sibling, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 21:07 UTC (permalink / raw) To: Stephen J. Turnbull Cc: esr, kfogel, toby-dated-1389906911.cc0ede, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 21:07 ` Eli Zaretskii @ 2014-01-04 5:01 ` Stephen J. Turnbull 2014-01-05 10:10 ` Florian Weimer 0 siblings, 1 reply; 123+ messages in thread From: Stephen J. Turnbull @ 2014-01-04 5:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, toby-dated-1389906911.cc0ede, emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 5:01 ` Stephen J. Turnbull @ 2014-01-05 10:10 ` Florian Weimer 0 siblings, 0 replies; 123+ messages in thread From: Florian Weimer @ 2014-01-05 10:10 UTC (permalink / raw) To: Stephen J. Turnbull Cc: esr, kfogel, Eli Zaretskii, toby-dated-1389906911.cc0ede, emacs-devel * 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* RE: Apologia for bzr 2014-01-03 20:34 ` Stephen J. Turnbull 2014-01-03 21:07 ` Eli Zaretskii @ 2020-10-29 7:11 ` Drew Adams 1 sibling, 0 replies; 123+ messages in thread From: Drew Adams @ 2020-10-29 7:11 UTC (permalink / raw) To: Stephen J. Turnbull, Eli Zaretskii; +Cc: esr, kfogel, Toby Cubitt, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 21:14 ` Toby Cubitt 2014-01-03 8:57 ` Eli Zaretskii @ 2014-01-03 14:37 ` Richard Stallman 2014-01-03 15:21 ` Toby Cubitt 1 sibling, 1 reply; 123+ messages in thread From: Richard Stallman @ 2014-01-03 14:37 UTC (permalink / raw) To: Toby Cubitt; +Cc: esr, kfogel, eliz, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 14:37 ` Richard Stallman @ 2014-01-03 15:21 ` Toby Cubitt 2014-01-04 7:59 ` Richard Stallman 0 siblings, 1 reply; 123+ messages in thread From: Toby Cubitt @ 2014-01-03 15:21 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 15:21 ` Toby Cubitt @ 2014-01-04 7:59 ` Richard Stallman 2014-01-04 8:28 ` Eric S. Raymond 0 siblings, 1 reply; 123+ messages in thread From: Richard Stallman @ 2014-01-04 7:59 UTC (permalink / raw) To: Toby Cubitt; +Cc: emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 7:59 ` Richard Stallman @ 2014-01-04 8:28 ` Eric S. Raymond 2014-01-04 12:09 ` Lennart Borgman 2014-01-05 20:20 ` Richard Stallman 0 siblings, 2 replies; 123+ messages in thread From: Eric S. Raymond @ 2014-01-04 8:28 UTC (permalink / raw) To: Richard Stallman; +Cc: Toby Cubitt, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 8:28 ` Eric S. Raymond @ 2014-01-04 12:09 ` Lennart Borgman 2014-01-04 15:44 ` Tom 2014-01-05 10:03 ` Stephen J. Turnbull 2014-01-05 20:20 ` Richard Stallman 1 sibling, 2 replies; 123+ messages in thread From: Lennart Borgman @ 2014-01-04 12:09 UTC (permalink / raw) To: esr; +Cc: Toby Cubitt, Richard Stallman, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 12:09 ` Lennart Borgman @ 2014-01-04 15:44 ` Tom 2014-01-04 19:00 ` David Kastrup 2014-01-05 10:03 ` Stephen J. Turnbull 1 sibling, 1 reply; 123+ messages in thread From: Tom @ 2014-01-04 15:44 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 15:44 ` Tom @ 2014-01-04 19:00 ` David Kastrup 2014-01-04 19:38 ` Lennart Borgman 2014-01-04 20:48 ` Tom 0 siblings, 2 replies; 123+ messages in thread From: David Kastrup @ 2014-01-04 19:00 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 19:00 ` David Kastrup @ 2014-01-04 19:38 ` Lennart Borgman 2014-01-04 20:48 ` Tom 1 sibling, 0 replies; 123+ messages in thread From: Lennart Borgman @ 2014-01-04 19:38 UTC (permalink / raw) To: David Kastrup; +Cc: Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 19:00 ` David Kastrup 2014-01-04 19:38 ` Lennart Borgman @ 2014-01-04 20:48 ` Tom 1 sibling, 0 replies; 123+ messages in thread From: Tom @ 2014-01-04 20:48 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 12:09 ` Lennart Borgman 2014-01-04 15:44 ` Tom @ 2014-01-05 10:03 ` Stephen J. Turnbull 2014-01-05 11:52 ` Eric S. Raymond 2014-01-05 14:27 ` Lennart Borgman 1 sibling, 2 replies; 123+ messages in thread From: Stephen J. Turnbull @ 2014-01-05 10:03 UTC (permalink / raw) To: Lennart Borgman; +Cc: esr, Richard Stallman, Emacs-Devel devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 10:03 ` Stephen J. Turnbull @ 2014-01-05 11:52 ` Eric S. Raymond 2014-01-05 18:14 ` Stephen J. Turnbull 2014-01-05 14:27 ` Lennart Borgman 1 sibling, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-05 11:52 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Lennart Borgman, Richard Stallman, Emacs-Devel devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 11:52 ` Eric S. Raymond @ 2014-01-05 18:14 ` Stephen J. Turnbull 0 siblings, 0 replies; 123+ messages in thread From: Stephen J. Turnbull @ 2014-01-05 18:14 UTC (permalink / raw) To: esr; +Cc: Lennart Borgman, Richard Stallman, Emacs-Devel devel 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! ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 10:03 ` Stephen J. Turnbull 2014-01-05 11:52 ` Eric S. Raymond @ 2014-01-05 14:27 ` Lennart Borgman 2014-01-05 15:27 ` David Kastrup 1 sibling, 1 reply; 123+ messages in thread From: Lennart Borgman @ 2014-01-05 14:27 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: Eric Raymond, Richard Stallman, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 14:27 ` Lennart Borgman @ 2014-01-05 15:27 ` David Kastrup 2014-01-05 15:56 ` Werner LEMBERG 0 siblings, 1 reply; 123+ messages in thread From: David Kastrup @ 2014-01-05 15:27 UTC (permalink / raw) To: Lennart Borgman Cc: Eric Raymond, Stephen J. Turnbull, Richard Stallman, Emacs-Devel devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 15:27 ` David Kastrup @ 2014-01-05 15:56 ` Werner LEMBERG 0 siblings, 0 replies; 123+ messages in thread From: Werner LEMBERG @ 2014-01-05 15:56 UTC (permalink / raw) To: dak; +Cc: esr, stephen, lennart.borgman, rms, emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 8:28 ` Eric S. Raymond 2014-01-04 12:09 ` Lennart Borgman @ 2014-01-05 20:20 ` Richard Stallman 2014-01-05 20:35 ` Gabriel Beauchamp ` (2 more replies) 1 sibling, 3 replies; 123+ messages in thread From: Richard Stallman @ 2014-01-05 20:20 UTC (permalink / raw) To: esr; +Cc: toby-dated-1389972095.0848dd, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:20 ` Richard Stallman @ 2014-01-05 20:35 ` Gabriel Beauchamp 2014-01-06 4:07 ` Yuri Khan 2014-01-05 20:41 ` Lennart Borgman 2014-01-05 20:56 ` Eric S. Raymond 2 siblings, 1 reply; 123+ messages in thread From: Gabriel Beauchamp @ 2014-01-05 20:35 UTC (permalink / raw) To: rms; +Cc: esr, toby-dated-1389972095.0848dd, emacs-devel 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. > > > ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:35 ` Gabriel Beauchamp @ 2014-01-06 4:07 ` Yuri Khan 0 siblings, 0 replies; 123+ messages in thread From: Yuri Khan @ 2014-01-06 4:07 UTC (permalink / raw) To: Gabriel Beauchamp Cc: Eric Raymond, toby-dated-1389972095.0848dd, rms, Emacs developers 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:20 ` Richard Stallman 2014-01-05 20:35 ` Gabriel Beauchamp @ 2014-01-05 20:41 ` Lennart Borgman 2014-01-05 21:31 ` Tom 2014-01-06 14:00 ` Richard Stallman 2014-01-05 20:56 ` Eric S. Raymond 2 siblings, 2 replies; 123+ messages in thread From: Lennart Borgman @ 2014-01-05 20:41 UTC (permalink / raw) To: Richard M. Stallman; +Cc: Eric Raymond, Toby Cubitt, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:41 ` Lennart Borgman @ 2014-01-05 21:31 ` Tom 2014-01-06 14:00 ` Richard Stallman 1 sibling, 0 replies; 123+ messages in thread From: Tom @ 2014-01-05 21:31 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:41 ` Lennart Borgman 2014-01-05 21:31 ` Tom @ 2014-01-06 14:00 ` Richard Stallman 2014-01-06 14:29 ` Lennart Borgman ` (2 more replies) 1 sibling, 3 replies; 123+ messages in thread From: Richard Stallman @ 2014-01-06 14:00 UTC (permalink / raw) To: Lennart Borgman; +Cc: esr, toby-dated-1389972095.0848dd, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:00 ` Richard Stallman @ 2014-01-06 14:29 ` Lennart Borgman 2014-01-06 15:14 ` John Yates ` (3 more replies) 2014-01-06 14:55 ` Stefan Monnier 2014-01-07 5:58 ` Christophe Poncy 2 siblings, 4 replies; 123+ messages in thread From: Lennart Borgman @ 2014-01-06 14:29 UTC (permalink / raw) To: Richard M. Stallman; +Cc: Eric Raymond, Toby Cubitt, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:29 ` Lennart Borgman @ 2014-01-06 15:14 ` John Yates 2014-01-06 20:27 ` Richard Stallman ` (2 subsequent siblings) 3 siblings, 0 replies; 123+ messages in thread From: John Yates @ 2014-01-06 15:14 UTC (permalink / raw) To: Lennart Borgman Cc: Eric Raymond, Toby Cubitt, Richard M. Stallman, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:29 ` Lennart Borgman 2014-01-06 15:14 ` John Yates @ 2014-01-06 20:27 ` Richard Stallman 2014-01-06 20:32 ` Daniel Colascione 2014-01-07 0:12 ` Stefan Monnier 2014-01-06 20:27 ` Richard Stallman 2014-01-07 6:03 ` Christophe Poncy 3 siblings, 2 replies; 123+ messages in thread From: Richard Stallman @ 2014-01-06 20:27 UTC (permalink / raw) To: Lennart Borgman; +Cc: esr, toby-dated-1389972095.0848dd, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 20:27 ` Richard Stallman @ 2014-01-06 20:32 ` Daniel Colascione 2014-01-06 23:43 ` Lennart Borgman ` (2 more replies) 2014-01-07 0:12 ` Stefan Monnier 1 sibling, 3 replies; 123+ messages in thread From: Daniel Colascione @ 2014-01-06 20:32 UTC (permalink / raw) To: rms, Lennart Borgman; +Cc: esr, toby-dated-1389972095.0848dd, emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 20:32 ` Daniel Colascione @ 2014-01-06 23:43 ` Lennart Borgman 2014-01-06 23:50 ` David Kastrup 2014-01-07 6:05 ` Christophe Poncy 2014-01-07 16:53 ` Richard Stallman 2 siblings, 1 reply; 123+ messages in thread From: Lennart Borgman @ 2014-01-06 23:43 UTC (permalink / raw) To: Daniel Colascione Cc: Eric Raymond, Toby Cubitt, Richard M. Stallman, Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 23:43 ` Lennart Borgman @ 2014-01-06 23:50 ` David Kastrup 2014-01-07 0:02 ` Lennart Borgman 0 siblings, 1 reply; 123+ messages in thread From: David Kastrup @ 2014-01-06 23:50 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 23:50 ` David Kastrup @ 2014-01-07 0:02 ` Lennart Borgman 2014-01-07 8:27 ` Thien-Thi Nguyen 0 siblings, 1 reply; 123+ messages in thread From: Lennart Borgman @ 2014-01-07 0:02 UTC (permalink / raw) To: David Kastrup; +Cc: Emacs-Devel devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 0:02 ` Lennart Borgman @ 2014-01-07 8:27 ` Thien-Thi Nguyen 0 siblings, 0 replies; 123+ messages in thread From: Thien-Thi Nguyen @ 2014-01-07 8:27 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 20:32 ` Daniel Colascione 2014-01-06 23:43 ` Lennart Borgman @ 2014-01-07 6:05 ` Christophe Poncy 2014-01-07 16:53 ` Richard Stallman 2 siblings, 0 replies; 123+ messages in thread From: Christophe Poncy @ 2014-01-07 6:05 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 20:32 ` Daniel Colascione 2014-01-06 23:43 ` Lennart Borgman 2014-01-07 6:05 ` Christophe Poncy @ 2014-01-07 16:53 ` Richard Stallman 2 siblings, 0 replies; 123+ messages in thread From: Richard Stallman @ 2014-01-07 16:53 UTC (permalink / raw) To: Daniel Colascione Cc: esr, toby-dated-1389972095.0848dd, lennart.borgman, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 20:27 ` Richard Stallman 2014-01-06 20:32 ` Daniel Colascione @ 2014-01-07 0:12 ` Stefan Monnier 2014-01-07 6:21 ` Lars Magne Ingebrigtsen 2014-01-07 6:22 ` Christophe Poncy 1 sibling, 2 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-07 0:12 UTC (permalink / raw) To: Richard Stallman Cc: esr, toby-dated-1389972095.0848dd, Lennart Borgman, emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 0:12 ` Stefan Monnier @ 2014-01-07 6:21 ` Lars Magne Ingebrigtsen 2014-01-07 10:30 ` Jose E. Marchesi 2014-01-07 6:22 ` Christophe Poncy 1 sibling, 1 reply; 123+ messages in thread From: Lars Magne Ingebrigtsen @ 2014-01-07 6:21 UTC (permalink / raw) To: Stefan Monnier Cc: esr, Lennart Borgman, toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 6:21 ` Lars Magne Ingebrigtsen @ 2014-01-07 10:30 ` Jose E. Marchesi 2014-01-09 14:10 ` Per Starbäck 0 siblings, 1 reply; 123+ messages in thread From: Jose E. Marchesi @ 2014-01-07 10:30 UTC (permalink / raw) To: Lars Magne Ingebrigtsen Cc: Richard Stallman, Lennart Borgman, toby-dated-1389972095.0848dd, emacs-devel, esr, Stefan Monnier > 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... ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 10:30 ` Jose E. Marchesi @ 2014-01-09 14:10 ` Per Starbäck 0 siblings, 0 replies; 123+ messages in thread From: Per Starbäck @ 2014-01-09 14:10 UTC (permalink / raw) To: emacs-devel@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 0:12 ` Stefan Monnier 2014-01-07 6:21 ` Lars Magne Ingebrigtsen @ 2014-01-07 6:22 ` Christophe Poncy 2014-01-07 6:41 ` joakim 1 sibling, 1 reply; 123+ messages in thread From: Christophe Poncy @ 2014-01-07 6:22 UTC (permalink / raw) To: emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-07 6:22 ` Christophe Poncy @ 2014-01-07 6:41 ` joakim 0 siblings, 0 replies; 123+ messages in thread From: joakim @ 2014-01-07 6:41 UTC (permalink / raw) To: Christophe Poncy; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:29 ` Lennart Borgman 2014-01-06 15:14 ` John Yates 2014-01-06 20:27 ` Richard Stallman @ 2014-01-06 20:27 ` Richard Stallman 2014-01-07 6:03 ` Christophe Poncy 3 siblings, 0 replies; 123+ messages in thread From: Richard Stallman @ 2014-01-06 20:27 UTC (permalink / raw) To: Lennart Borgman; +Cc: esr, toby-dated-1389972095.0848dd, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:29 ` Lennart Borgman ` (2 preceding siblings ...) 2014-01-06 20:27 ` Richard Stallman @ 2014-01-07 6:03 ` Christophe Poncy 3 siblings, 0 replies; 123+ messages in thread From: Christophe Poncy @ 2014-01-07 6:03 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:00 ` Richard Stallman 2014-01-06 14:29 ` Lennart Borgman @ 2014-01-06 14:55 ` Stefan Monnier 2014-01-07 5:58 ` Christophe Poncy 2 siblings, 0 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-06 14:55 UTC (permalink / raw) To: Richard Stallman Cc: esr, toby-dated-1389972095.0848dd, Lennart Borgman, emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:00 ` Richard Stallman 2014-01-06 14:29 ` Lennart Borgman 2014-01-06 14:55 ` Stefan Monnier @ 2014-01-07 5:58 ` Christophe Poncy 2 siblings, 0 replies; 123+ messages in thread From: Christophe Poncy @ 2014-01-07 5:58 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:20 ` Richard Stallman 2014-01-05 20:35 ` Gabriel Beauchamp 2014-01-05 20:41 ` Lennart Borgman @ 2014-01-05 20:56 ` Eric S. Raymond 2014-01-05 21:58 ` Florian Weimer ` (3 more replies) 2 siblings, 4 replies; 123+ messages in thread From: Eric S. Raymond @ 2014-01-05 20:56 UTC (permalink / raw) To: Richard Stallman; +Cc: toby-dated-1389972095.0848dd, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:56 ` Eric S. Raymond @ 2014-01-05 21:58 ` Florian Weimer 2014-01-05 22:13 ` chad 2014-01-05 23:41 ` James Cloos ` (2 subsequent siblings) 3 siblings, 1 reply; 123+ messages in thread From: Florian Weimer @ 2014-01-05 21:58 UTC (permalink / raw) To: esr; +Cc: toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel * 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 21:58 ` Florian Weimer @ 2014-01-05 22:13 ` chad 2014-01-05 22:25 ` Lennart Borgman 2014-01-05 22:54 ` Stefan Monnier 0 siblings, 2 replies; 123+ messages in thread From: chad @ 2014-01-05 22:13 UTC (permalink / raw) To: Florian Weimer Cc: esr, toby-dated-1389972095.0848dd, Richard Stallman, EMACS development team 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 22:13 ` chad @ 2014-01-05 22:25 ` Lennart Borgman 2014-01-05 23:01 ` chad 2014-01-05 22:54 ` Stefan Monnier 1 sibling, 1 reply; 123+ messages in thread From: Lennart Borgman @ 2014-01-05 22:25 UTC (permalink / raw) To: chad Cc: Eric Raymond, Florian Weimer, Toby Cubitt, Richard Stallman, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 22:25 ` Lennart Borgman @ 2014-01-05 23:01 ` chad 2014-01-06 2:32 ` Lennart Borgman 0 siblings, 1 reply; 123+ messages in thread From: chad @ 2014-01-05 23:01 UTC (permalink / raw) To: Lennart Borgman Cc: Eric Raymond, Florian Weimer, Toby Cubitt, Richard Stallman, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 23:01 ` chad @ 2014-01-06 2:32 ` Lennart Borgman 0 siblings, 0 replies; 123+ messages in thread From: Lennart Borgman @ 2014-01-06 2:32 UTC (permalink / raw) To: chad Cc: Eric Raymond, Florian Weimer, Toby Cubitt, Richard Stallman, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 22:13 ` chad 2014-01-05 22:25 ` Lennart Borgman @ 2014-01-05 22:54 ` Stefan Monnier 2014-01-06 14:09 ` Sivaram Neelakantan 1 sibling, 1 reply; 123+ messages in thread From: Stefan Monnier @ 2014-01-05 22:54 UTC (permalink / raw) To: chad Cc: esr, Florian Weimer, toby-dated-1389972095.0848dd, Richard Stallman, EMACS development team > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 22:54 ` Stefan Monnier @ 2014-01-06 14:09 ` Sivaram Neelakantan 2014-01-06 14:54 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 123+ messages in thread From: Sivaram Neelakantan @ 2014-01-06 14:09 UTC (permalink / raw) To: emacs-devel 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 -- ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:09 ` Sivaram Neelakantan @ 2014-01-06 14:54 ` David Kastrup 2014-01-06 14:56 ` Stefan Monnier 2014-01-07 6:00 ` Christophe Poncy 2 siblings, 0 replies; 123+ messages in thread From: David Kastrup @ 2014-01-06 14:54 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:09 ` Sivaram Neelakantan 2014-01-06 14:54 ` David Kastrup @ 2014-01-06 14:56 ` Stefan Monnier 2014-01-07 6:00 ` Christophe Poncy 2 siblings, 0 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-06 14:56 UTC (permalink / raw) To: Sivaram Neelakantan; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 14:09 ` Sivaram Neelakantan 2014-01-06 14:54 ` David Kastrup 2014-01-06 14:56 ` Stefan Monnier @ 2014-01-07 6:00 ` Christophe Poncy 2 siblings, 0 replies; 123+ messages in thread From: Christophe Poncy @ 2014-01-07 6:00 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:56 ` Eric S. Raymond 2014-01-05 21:58 ` Florian Weimer @ 2014-01-05 23:41 ` James Cloos 2014-01-06 0:27 ` Karl Fogel ` (2 more replies) 2014-01-06 18:47 ` Eric Brown 2014-01-09 20:30 ` Rogerio Senna 3 siblings, 3 replies; 123+ messages in thread From: James Cloos @ 2014-01-05 23:41 UTC (permalink / raw) To: Eric S. Raymond Cc: toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 23:41 ` James Cloos @ 2014-01-06 0:27 ` Karl Fogel 2014-01-06 0:35 ` Eric S. Raymond 2014-01-06 0:45 ` David Kastrup 2 siblings, 0 replies; 123+ messages in thread From: Karl Fogel @ 2014-01-06 0:27 UTC (permalink / raw) To: James Cloos Cc: Eric S. Raymond, toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel 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 :-). ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 23:41 ` James Cloos 2014-01-06 0:27 ` Karl Fogel @ 2014-01-06 0:35 ` Eric S. Raymond 2014-01-06 0:45 ` David Kastrup 2 siblings, 0 replies; 123+ messages in thread From: Eric S. Raymond @ 2014-01-06 0:35 UTC (permalink / raw) To: James Cloos; +Cc: toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 23:41 ` James Cloos 2014-01-06 0:27 ` Karl Fogel 2014-01-06 0:35 ` Eric S. Raymond @ 2014-01-06 0:45 ` David Kastrup 2014-01-06 1:52 ` Eric Brown ` (2 more replies) 2 siblings, 3 replies; 123+ messages in thread From: David Kastrup @ 2014-01-06 0:45 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 0:45 ` David Kastrup @ 2014-01-06 1:52 ` Eric Brown 2014-01-06 2:08 ` David Kastrup 2014-01-06 4:27 ` Yuri Khan 2014-01-06 15:40 ` James Cloos 2 siblings, 1 reply; 123+ messages in thread From: Eric Brown @ 2014-01-06 1:52 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel 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.) ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 1:52 ` Eric Brown @ 2014-01-06 2:08 ` David Kastrup 0 siblings, 0 replies; 123+ messages in thread From: David Kastrup @ 2014-01-06 2:08 UTC (permalink / raw) To: Eric Brown; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 0:45 ` David Kastrup 2014-01-06 1:52 ` Eric Brown @ 2014-01-06 4:27 ` Yuri Khan 2014-01-06 7:18 ` Michael Albinus 2014-01-06 7:32 ` chad 2014-01-06 15:40 ` James Cloos 2 siblings, 2 replies; 123+ messages in thread From: Yuri Khan @ 2014-01-06 4:27 UTC (permalink / raw) To: David Kastrup; +Cc: Emacs developers 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?) ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 4:27 ` Yuri Khan @ 2014-01-06 7:18 ` Michael Albinus 2014-01-06 7:32 ` chad 1 sibling, 0 replies; 123+ messages in thread From: Michael Albinus @ 2014-01-06 7:18 UTC (permalink / raw) To: Yuri Khan; +Cc: David Kastrup, Emacs developers 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 4:27 ` Yuri Khan 2014-01-06 7:18 ` Michael Albinus @ 2014-01-06 7:32 ` chad 1 sibling, 0 replies; 123+ messages in thread From: chad @ 2014-01-06 7:32 UTC (permalink / raw) To: Yuri Khan; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-06 0:45 ` David Kastrup 2014-01-06 1:52 ` Eric Brown 2014-01-06 4:27 ` Yuri Khan @ 2014-01-06 15:40 ` James Cloos 2 siblings, 0 replies; 123+ messages in thread From: James Cloos @ 2014-01-06 15:40 UTC (permalink / raw) To: David Kastrup; +Cc: emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:56 ` Eric S. Raymond 2014-01-05 21:58 ` Florian Weimer 2014-01-05 23:41 ` James Cloos @ 2014-01-06 18:47 ` Eric Brown 2014-01-09 20:30 ` Rogerio Senna 3 siblings, 0 replies; 123+ messages in thread From: Eric Brown @ 2014-01-06 18:47 UTC (permalink / raw) To: esr; +Cc: toby-dated-1389972095.0848dd, Richard Stallman, emacs-devel "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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-05 20:56 ` Eric S. Raymond ` (2 preceding siblings ...) 2014-01-06 18:47 ` Eric Brown @ 2014-01-09 20:30 ` Rogerio Senna 2014-01-09 22:05 ` Drew Adams 3 siblings, 1 reply; 123+ messages in thread From: Rogerio Senna @ 2014-01-09 20:30 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 123+ messages in thread
* RE: Apologia for bzr 2014-01-09 20:30 ` Rogerio Senna @ 2014-01-09 22:05 ` Drew Adams 0 siblings, 0 replies; 123+ messages in thread From: Drew Adams @ 2014-01-09 22:05 UTC (permalink / raw) To: Rogerio Senna, emacs-devel >>> 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-02 20:44 ` Eli Zaretskii 2014-01-02 20:51 ` Eric S. Raymond 2014-01-02 21:14 ` Toby Cubitt @ 2014-01-03 9:44 ` Tassilo Horn 2014-01-03 10:26 ` Eli Zaretskii 2 siblings, 1 reply; 123+ messages in thread From: Tassilo Horn @ 2014-01-03 9:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 9:44 ` Tassilo Horn @ 2014-01-03 10:26 ` Eli Zaretskii 2014-01-03 10:56 ` Nathan Trapuzzano ` (2 more replies) 0 siblings, 3 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 10:26 UTC (permalink / raw) To: Tassilo Horn; +Cc: esr, kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 10:26 ` Eli Zaretskii @ 2014-01-03 10:56 ` Nathan Trapuzzano 2014-01-03 11:45 ` Eli Zaretskii 2014-01-03 13:49 ` Leo Liu 2014-01-03 16:57 ` Tassilo Horn 2 siblings, 1 reply; 123+ messages in thread From: Nathan Trapuzzano @ 2014-01-03 10:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel, Tassilo Horn 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 10:56 ` Nathan Trapuzzano @ 2014-01-03 11:45 ` Eli Zaretskii 2014-01-03 11:49 ` Nathan Trapuzzano 2014-01-03 15:06 ` Óscar Fuentes 0 siblings, 2 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 11:45 UTC (permalink / raw) To: Nathan Trapuzzano; +Cc: esr, kfogel, emacs-devel, tsdh > 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/. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 11:45 ` Eli Zaretskii @ 2014-01-03 11:49 ` Nathan Trapuzzano 2014-01-03 13:54 ` Eli Zaretskii 2014-01-03 15:06 ` Óscar Fuentes 1 sibling, 1 reply; 123+ messages in thread From: Nathan Trapuzzano @ 2014-01-03 11:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, tsdh, emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 11:49 ` Nathan Trapuzzano @ 2014-01-03 13:54 ` Eli Zaretskii 2014-01-04 20:37 ` Eli Zaretskii 0 siblings, 1 reply; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 13:54 UTC (permalink / raw) To: Nathan Trapuzzano; +Cc: esr, kfogel, tsdh, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 13:54 ` Eli Zaretskii @ 2014-01-04 20:37 ` Eli Zaretskii 0 siblings, 0 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-04 20:37 UTC (permalink / raw) To: nbtrap; +Cc: esr, kfogel, emacs-devel, tsdh > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 11:45 ` Eli Zaretskii 2014-01-03 11:49 ` Nathan Trapuzzano @ 2014-01-03 15:06 ` Óscar Fuentes 2014-01-03 15:34 ` Eli Zaretskii 1 sibling, 1 reply; 123+ messages in thread From: Óscar Fuentes @ 2014-01-03 15:06 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 15:06 ` Óscar Fuentes @ 2014-01-03 15:34 ` Eli Zaretskii 0 siblings, 0 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 15:34 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 10:26 ` Eli Zaretskii 2014-01-03 10:56 ` Nathan Trapuzzano @ 2014-01-03 13:49 ` Leo Liu 2014-01-03 14:08 ` Eli Zaretskii 2014-01-03 17:45 ` Eric S. Raymond 2014-01-03 16:57 ` Tassilo Horn 2 siblings, 2 replies; 123+ messages in thread From: Leo Liu @ 2014-01-03 13:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel, Tassilo Horn 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 13:49 ` Leo Liu @ 2014-01-03 14:08 ` Eli Zaretskii 2014-01-03 15:12 ` Óscar Fuentes 2014-01-03 19:49 ` Stefan Monnier 2014-01-03 17:45 ` Eric S. Raymond 1 sibling, 2 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 14:08 UTC (permalink / raw) To: emacs-devel; +Cc: esr, kfogel, emacs-devel, tsdh > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 14:08 ` Eli Zaretskii @ 2014-01-03 15:12 ` Óscar Fuentes 2014-01-03 17:48 ` Eric S. Raymond 2014-01-03 19:39 ` Stefan Monnier 2014-01-03 19:49 ` Stefan Monnier 1 sibling, 2 replies; 123+ messages in thread From: Óscar Fuentes @ 2014-01-03 15:12 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 15:12 ` Óscar Fuentes @ 2014-01-03 17:48 ` Eric S. Raymond 2014-01-03 19:39 ` Stefan Monnier 1 sibling, 0 replies; 123+ messages in thread From: Eric S. Raymond @ 2014-01-03 17:48 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel Ó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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 15:12 ` Óscar Fuentes 2014-01-03 17:48 ` Eric S. Raymond @ 2014-01-03 19:39 ` Stefan Monnier 1 sibling, 0 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-03 19:39 UTC (permalink / raw) To: Óscar Fuentes; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 14:08 ` Eli Zaretskii 2014-01-03 15:12 ` Óscar Fuentes @ 2014-01-03 19:49 ` Stefan Monnier 2014-01-03 20:27 ` David Kastrup ` (2 more replies) 1 sibling, 3 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-03 19:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, tsdh, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 19:49 ` Stefan Monnier @ 2014-01-03 20:27 ` David Kastrup 2014-01-03 20:39 ` Dmitry Gutov 2014-01-04 2:00 ` Josh 2 siblings, 0 replies; 123+ messages in thread From: David Kastrup @ 2014-01-03 20:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel, tsdh 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 19:49 ` Stefan Monnier 2014-01-03 20:27 ` David Kastrup @ 2014-01-03 20:39 ` Dmitry Gutov 2014-01-03 20:54 ` Eric S. Raymond 2014-01-04 4:06 ` Stefan Monnier 2014-01-04 2:00 ` Josh 2 siblings, 2 replies; 123+ messages in thread From: Dmitry Gutov @ 2014-01-03 20:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel, tsdh 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:39 ` Dmitry Gutov @ 2014-01-03 20:54 ` Eric S. Raymond 2014-01-04 4:06 ` Stefan Monnier 1 sibling, 0 replies; 123+ messages in thread From: Eric S. Raymond @ 2014-01-03 20:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: kfogel, Eli Zaretskii, emacs-devel, Stefan Monnier, tsdh 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:39 ` Dmitry Gutov 2014-01-03 20:54 ` Eric S. Raymond @ 2014-01-04 4:06 ` Stefan Monnier 1 sibling, 0 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-04 4:06 UTC (permalink / raw) To: Dmitry Gutov; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel, tsdh >> 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 19:49 ` Stefan Monnier 2014-01-03 20:27 ` David Kastrup 2014-01-03 20:39 ` Dmitry Gutov @ 2014-01-04 2:00 ` Josh 2 siblings, 0 replies; 123+ messages in thread From: Josh @ 2014-01-04 2:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel, tsdh 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 13:49 ` Leo Liu 2014-01-03 14:08 ` Eli Zaretskii @ 2014-01-03 17:45 ` Eric S. Raymond 2014-01-03 17:56 ` Karl Fogel 1 sibling, 1 reply; 123+ messages in thread From: Eric S. Raymond @ 2014-01-03 17:45 UTC (permalink / raw) To: emacs-devel; +Cc: kfogel, Eli Zaretskii, Tassilo Horn 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> ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 17:45 ` Eric S. Raymond @ 2014-01-03 17:56 ` Karl Fogel 2014-01-03 18:04 ` Ted Zlatanov ` (2 more replies) 0 siblings, 3 replies; 123+ messages in thread From: Karl Fogel @ 2014-01-03 17:56 UTC (permalink / raw) To: Eric S. Raymond; +Cc: Eli Zaretskii, Tassilo Horn, emacs-devel "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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 17:56 ` Karl Fogel @ 2014-01-03 18:04 ` Ted Zlatanov 2014-01-03 18:21 ` Karl Fogel 2014-01-03 19:19 ` chad 2014-01-03 18:05 ` David Engster 2014-01-04 13:08 ` Bastien 2 siblings, 2 replies; 123+ messages in thread From: Ted Zlatanov @ 2014-01-03 18:04 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 18:04 ` Ted Zlatanov @ 2014-01-03 18:21 ` Karl Fogel 2014-01-03 19:52 ` Stefan Monnier 2014-01-03 19:19 ` chad 1 sibling, 1 reply; 123+ messages in thread From: Karl Fogel @ 2014-01-03 18:21 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 18:21 ` Karl Fogel @ 2014-01-03 19:52 ` Stefan Monnier 2014-01-03 20:17 ` Karl Fogel 2014-01-04 10:01 ` David Engster 0 siblings, 2 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-03 19:52 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 19:52 ` Stefan Monnier @ 2014-01-03 20:17 ` Karl Fogel 2014-01-04 10:01 ` David Engster 1 sibling, 0 replies; 123+ messages in thread From: Karl Fogel @ 2014-01-03 20:17 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 19:52 ` Stefan Monnier 2014-01-03 20:17 ` Karl Fogel @ 2014-01-04 10:01 ` David Engster 2014-01-04 19:53 ` Stefan Monnier 1 sibling, 1 reply; 123+ messages in thread From: David Engster @ 2014-01-04 10:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: Karl Fogel, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-04 10:01 ` David Engster @ 2014-01-04 19:53 ` Stefan Monnier 0 siblings, 0 replies; 123+ messages in thread From: Stefan Monnier @ 2014-01-04 19:53 UTC (permalink / raw) To: Karl Fogel; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 18:04 ` Ted Zlatanov 2014-01-03 18:21 ` Karl Fogel @ 2014-01-03 19:19 ` chad 1 sibling, 0 replies; 123+ messages in thread From: chad @ 2014-01-03 19:19 UTC (permalink / raw) To: EMACS development team 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 17:56 ` Karl Fogel 2014-01-03 18:04 ` Ted Zlatanov @ 2014-01-03 18:05 ` David Engster 2014-01-04 13:08 ` Bastien 2 siblings, 0 replies; 123+ messages in thread From: David Engster @ 2014-01-03 18:05 UTC (permalink / raw) To: Karl Fogel; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel, Tassilo Horn 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 17:56 ` Karl Fogel 2014-01-03 18:04 ` Ted Zlatanov 2014-01-03 18:05 ` David Engster @ 2014-01-04 13:08 ` Bastien 2 siblings, 0 replies; 123+ messages in thread From: Bastien @ 2014-01-04 13:08 UTC (permalink / raw) To: Karl Fogel; +Cc: Eric S. Raymond, Eli Zaretskii, emacs-devel, Tassilo Horn 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 10:26 ` Eli Zaretskii 2014-01-03 10:56 ` Nathan Trapuzzano 2014-01-03 13:49 ` Leo Liu @ 2014-01-03 16:57 ` Tassilo Horn 2014-01-03 20:02 ` Ulrich Mueller 2014-01-03 20:14 ` Eli Zaretskii 2 siblings, 2 replies; 123+ messages in thread From: Tassilo Horn @ 2014-01-03 16:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 16:57 ` Tassilo Horn @ 2014-01-03 20:02 ` Ulrich Mueller 2014-01-03 20:13 ` Tassilo Horn 2014-01-03 20:32 ` Eli Zaretskii 2014-01-03 20:14 ` Eli Zaretskii 1 sibling, 2 replies; 123+ messages in thread From: Ulrich Mueller @ 2014-01-03 20:02 UTC (permalink / raw) To: Tassilo Horn; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel >>>>> 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:02 ` Ulrich Mueller @ 2014-01-03 20:13 ` Tassilo Horn 2014-01-03 20:32 ` Eli Zaretskii 1 sibling, 0 replies; 123+ messages in thread From: Tassilo Horn @ 2014-01-03 20:13 UTC (permalink / raw) To: Ulrich Mueller; +Cc: esr, kfogel, Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:02 ` Ulrich Mueller 2014-01-03 20:13 ` Tassilo Horn @ 2014-01-03 20:32 ` Eli Zaretskii 1 sibling, 0 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 20:32 UTC (permalink / raw) To: Ulrich Mueller; +Cc: esr, kfogel, emacs-devel, tsdh > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 16:57 ` Tassilo Horn 2014-01-03 20:02 ` Ulrich Mueller @ 2014-01-03 20:14 ` Eli Zaretskii 2014-01-03 20:50 ` Óscar Fuentes 2014-01-03 21:10 ` Tassilo Horn 1 sibling, 2 replies; 123+ messages in thread From: Eli Zaretskii @ 2014-01-03 20:14 UTC (permalink / raw) To: Tassilo Horn; +Cc: esr, kfogel, emacs-devel > 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:14 ` Eli Zaretskii @ 2014-01-03 20:50 ` Óscar Fuentes 2014-01-03 21:10 ` Tassilo Horn 1 sibling, 0 replies; 123+ messages in thread From: Óscar Fuentes @ 2014-01-03 20:50 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 123+ messages in thread
* Re: Apologia for bzr 2014-01-03 20:14 ` Eli Zaretskii 2014-01-03 20:50 ` Óscar Fuentes @ 2014-01-03 21:10 ` Tassilo Horn 1 sibling, 0 replies; 123+ messages in thread From: Tassilo Horn @ 2014-01-03 21:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: esr, kfogel, emacs-devel 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 ^ permalink raw reply [flat|nested] 123+ messages in thread
end of thread, other threads:[~2020-10-29 7:11 UTC | newest] Thread overview: 123+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-07 9:32 Apologia for bzr Alexander Meesters -- strict thread matches above, loose matches on Subject: below -- 2014-01-02 9:53 bzr is dying; Emacs needs to move Eric S. Raymond 2014-01-02 15:04 ` Richard Stallman 2014-01-02 15:41 ` PROPOSAL: Move to git, now that bzr is no longer a req Karl Fogel 2014-01-02 17:10 ` Eli Zaretskii 2014-01-02 17:28 ` Eric S. Raymond 2014-01-02 17:56 ` Eli Zaretskii 2014-01-02 18:34 ` Apologia for bzr Eric S. Raymond 2014-01-02 20:44 ` Eli Zaretskii 2014-01-02 20:51 ` Eric S. Raymond 2014-01-02 21:03 ` Eli Zaretskii 2014-01-02 21:15 ` Juanma Barranquero 2014-01-03 7:47 ` Eli Zaretskii 2014-01-03 11:11 ` Juanma Barranquero 2014-01-03 11:46 ` Eli Zaretskii 2014-01-03 11:55 ` Juanma Barranquero 2014-01-02 21:31 ` Óscar Fuentes 2014-01-02 21:14 ` Toby Cubitt 2014-01-03 8:57 ` Eli Zaretskii 2014-01-03 9:21 ` Yuri Khan 2014-01-03 10:08 ` Eli Zaretskii 2014-01-03 20:34 ` Stephen J. Turnbull 2014-01-03 21:07 ` Eli Zaretskii 2014-01-04 5:01 ` Stephen J. Turnbull 2014-01-05 10:10 ` Florian Weimer 2020-10-29 7:11 ` Drew Adams 2014-01-03 14:37 ` Richard Stallman 2014-01-03 15:21 ` Toby Cubitt 2014-01-04 7:59 ` Richard Stallman 2014-01-04 8:28 ` Eric S. Raymond 2014-01-04 12:09 ` Lennart Borgman 2014-01-04 15:44 ` Tom 2014-01-04 19:00 ` David Kastrup 2014-01-04 19:38 ` Lennart Borgman 2014-01-04 20:48 ` Tom 2014-01-05 10:03 ` Stephen J. Turnbull 2014-01-05 11:52 ` Eric S. Raymond 2014-01-05 18:14 ` Stephen J. Turnbull 2014-01-05 14:27 ` Lennart Borgman 2014-01-05 15:27 ` David Kastrup 2014-01-05 15:56 ` Werner LEMBERG 2014-01-05 20:20 ` Richard Stallman 2014-01-05 20:35 ` Gabriel Beauchamp 2014-01-06 4:07 ` Yuri Khan 2014-01-05 20:41 ` Lennart Borgman 2014-01-05 21:31 ` Tom 2014-01-06 14:00 ` Richard Stallman 2014-01-06 14:29 ` Lennart Borgman 2014-01-06 15:14 ` John Yates 2014-01-06 20:27 ` Richard Stallman 2014-01-06 20:32 ` Daniel Colascione 2014-01-06 23:43 ` Lennart Borgman 2014-01-06 23:50 ` David Kastrup 2014-01-07 0:02 ` Lennart Borgman 2014-01-07 8:27 ` Thien-Thi Nguyen 2014-01-07 6:05 ` Christophe Poncy 2014-01-07 16:53 ` Richard Stallman 2014-01-07 0:12 ` Stefan Monnier 2014-01-07 6:21 ` Lars Magne Ingebrigtsen 2014-01-07 10:30 ` Jose E. Marchesi 2014-01-09 14:10 ` Per Starbäck 2014-01-07 6:22 ` Christophe Poncy 2014-01-07 6:41 ` joakim 2014-01-06 20:27 ` Richard Stallman 2014-01-07 6:03 ` Christophe Poncy 2014-01-06 14:55 ` Stefan Monnier 2014-01-07 5:58 ` Christophe Poncy 2014-01-05 20:56 ` Eric S. Raymond 2014-01-05 21:58 ` Florian Weimer 2014-01-05 22:13 ` chad 2014-01-05 22:25 ` Lennart Borgman 2014-01-05 23:01 ` chad 2014-01-06 2:32 ` Lennart Borgman 2014-01-05 22:54 ` Stefan Monnier 2014-01-06 14:09 ` Sivaram Neelakantan 2014-01-06 14:54 ` David Kastrup 2014-01-06 14:56 ` Stefan Monnier 2014-01-07 6:00 ` Christophe Poncy 2014-01-05 23:41 ` James Cloos 2014-01-06 0:27 ` Karl Fogel 2014-01-06 0:35 ` Eric S. Raymond 2014-01-06 0:45 ` David Kastrup 2014-01-06 1:52 ` Eric Brown 2014-01-06 2:08 ` David Kastrup 2014-01-06 4:27 ` Yuri Khan 2014-01-06 7:18 ` Michael Albinus 2014-01-06 7:32 ` chad 2014-01-06 15:40 ` James Cloos 2014-01-06 18:47 ` Eric Brown 2014-01-09 20:30 ` Rogerio Senna 2014-01-09 22:05 ` Drew Adams 2014-01-03 9:44 ` Tassilo Horn 2014-01-03 10:26 ` Eli Zaretskii 2014-01-03 10:56 ` Nathan Trapuzzano 2014-01-03 11:45 ` Eli Zaretskii 2014-01-03 11:49 ` Nathan Trapuzzano 2014-01-03 13:54 ` Eli Zaretskii 2014-01-04 20:37 ` Eli Zaretskii 2014-01-03 15:06 ` Óscar Fuentes 2014-01-03 15:34 ` Eli Zaretskii 2014-01-03 13:49 ` Leo Liu 2014-01-03 14:08 ` Eli Zaretskii 2014-01-03 15:12 ` Óscar Fuentes 2014-01-03 17:48 ` Eric S. Raymond 2014-01-03 19:39 ` Stefan Monnier 2014-01-03 19:49 ` Stefan Monnier 2014-01-03 20:27 ` David Kastrup 2014-01-03 20:39 ` Dmitry Gutov 2014-01-03 20:54 ` Eric S. Raymond 2014-01-04 4:06 ` Stefan Monnier 2014-01-04 2:00 ` Josh 2014-01-03 17:45 ` Eric S. Raymond 2014-01-03 17:56 ` Karl Fogel 2014-01-03 18:04 ` Ted Zlatanov 2014-01-03 18:21 ` Karl Fogel 2014-01-03 19:52 ` Stefan Monnier 2014-01-03 20:17 ` Karl Fogel 2014-01-04 10:01 ` David Engster 2014-01-04 19:53 ` Stefan Monnier 2014-01-03 19:19 ` chad 2014-01-03 18:05 ` David Engster 2014-01-04 13:08 ` Bastien 2014-01-03 16:57 ` Tassilo Horn 2014-01-03 20:02 ` Ulrich Mueller 2014-01-03 20:13 ` Tassilo Horn 2014-01-03 20:32 ` Eli Zaretskii 2014-01-03 20:14 ` Eli Zaretskii 2014-01-03 20:50 ` Óscar Fuentes 2014-01-03 21:10 ` Tassilo Horn
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).