* Grouping related buffers @ 2008-11-10 15:21 Corey Foote 2008-11-10 16:43 ` Tassilo Horn ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Corey Foote @ 2008-11-10 15:21 UTC (permalink / raw) To: help-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 1121 bytes --] Hi everybody, As you probably already know, modern window managers support virtual desktops, which extend the workspace to multiple desktop areas. This allows users to spread the windows they have open across multiple workspaces, as an alternative to crowding them all on to one screen. I find this helpful because I work on multiple projects at a time, and having multiple desktops allows me to group the windows for each project together in separate desktops. I was wondering if there was a way to group related buffers in Emacs through the use of, say, multiple buffer workspaces. For example, it would be nice if when I display a list of existing buffers by typing C-x C-b it would be possible to group the buffers in the list, and when I called C-x b only the buffers in the current grouping would be available. (To get at the others it would be necessary to change the current buffer workspace.) Thanks! _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008 [-- Attachment #2: Type: text/html, Size: 1309 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Grouping related buffers 2008-11-10 15:21 Grouping related buffers Corey Foote @ 2008-11-10 16:43 ` Tassilo Horn 2008-11-10 17:24 ` Corey Foote 2008-11-10 18:26 ` Grouping related buffers Drew Adams [not found] ` <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org> 2 siblings, 1 reply; 25+ messages in thread From: Tassilo Horn @ 2008-11-10 16:43 UTC (permalink / raw) To: help-gnu-emacs Corey Foote <coreyfoote@hotmail.com> writes: Hi Corey! > I was wondering if there was a way to group related buffers in Emacs > through the use of, say, multiple buffer workspaces. There's desktop-save-mode which can be used therefore. See (info "(emacs)Saving Emacs Sessions") for details. It's not exactly like the grouping you'd like to have, because there's only one open workspace at a time and switching workspaces involves closing all files/buffers of the current one and loading the new ones. So quickly jumping between buffers of different workspaces is not possible. So many people open one emacs instance per workspace, which has other drawbacks of course. Hope that helps, Tassilo ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: Grouping related buffers 2008-11-10 16:43 ` Tassilo Horn @ 2008-11-10 17:24 ` Corey Foote 2008-11-10 18:05 ` learning Emacs Lisp [was: Grouping related buffers] Drew Adams [not found] ` <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 25+ messages in thread From: Corey Foote @ 2008-11-10 17:24 UTC (permalink / raw) To: help-gnu-emacs [-- Attachment #1: Type: text/plain, Size: 1766 bytes --] I actually don't think it would be too difficult to write something like this. It would involved modifying a few functions, and giving each buffer a variable which would identify it with one of the groups. I'm in the process of learning emacs lisp right now, but an no where near experienced enough to make a customization like this! By the way, does anybody have any recommendations on the best way to learn emacs lisp? I've got two books... the emacs lisp manual and an old O'Reilly book called Writing GNU Emacs Extensions by Bob Glickstein. It would be cool if there were a course I could take in programming this stuff... :-) > To: help-gnu-emacs@gnu.org > From: tassilo@member.fsf.org > Date: Mon, 10 Nov 2008 17:43:07 +0100 > Subject: Re: Grouping related buffers > > Corey Foote <coreyfoote@hotmail.com> writes: > > Hi Corey! > > > I was wondering if there was a way to group related buffers in Emacs > > through the use of, say, multiple buffer workspaces. > > There's desktop-save-mode which can be used therefore. See > > (info "(emacs)Saving Emacs Sessions") > > for details. It's not exactly like the grouping you'd like to have, > because there's only one open workspace at a time and switching > workspaces involves closing all files/buffers of the current one and > loading the new ones. So quickly jumping between buffers of different > workspaces is not possible. > > So many people open one emacs instance per workspace, which has other > drawbacks of course. > > Hope that helps, > Tassilo > > > _________________________________________________________________ Get 5 GB of storage with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008 [-- Attachment #2: Type: text/html, Size: 2112 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* learning Emacs Lisp [was: Grouping related buffers] 2008-11-10 17:24 ` Corey Foote @ 2008-11-10 18:05 ` Drew Adams [not found] ` <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 25+ messages in thread From: Drew Adams @ 2008-11-10 18:05 UTC (permalink / raw) To: 'Corey Foote', help-gnu-emacs > By the way, does anybody have any recommendations on the > best way to learn emacs lisp? I've got two books... the > emacs lisp manual and an old O'Reilly book called Writing > GNU Emacs Extensions by Bob Glickstein. It would be cool > if there were a course I could take in programming this > stuff... :-) [Please use plain text, not HTML, and please start a new thread for a new topic.] The Emacs Wiki has some help about this: http://www.emacswiki.org/emacs/LearningEmacs#LearnEmacsLisp I would also recommend this: Think of something simple that you would like to make Emacs do, and try to do it. In particular, try to modify some existing Lisp function or command in some way that you're interested in. This will get you to look at how things are done in the existing code, which is a great source for models. And the existing code works (!), so any departures you make from it can be compared when your changes don't do exactly what you expect. Another help is to get familiar with an Emacs-Lisp debugger - either edebug or the classic debugger (`debug-on-entry', put (debug) calls in your code, etc.). Likewise, functions `message', `sit-for', and `sleep-for' (for use with `message'). ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org>]
* Re: learning Emacs Lisp [not found] ` <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org> @ 2008-11-10 18:27 ` Richard Riley 2008-11-10 19:22 ` Tassilo Horn [not found] ` <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 25+ messages in thread From: Richard Riley @ 2008-11-10 18:27 UTC (permalink / raw) To: help-gnu-emacs "Drew Adams" <drew.adams@oracle.com> writes: >> By the way, does anybody have any recommendations on the >> best way to learn emacs lisp? I've got two books... the >> emacs lisp manual and an old O'Reilly book called Writing >> GNU Emacs Extensions by Bob Glickstein. It would be cool >> if there were a course I could take in programming this >> stuff... :-) > > [Please use plain text, not HTML, and please start a new thread for a new > topic.] > > The Emacs Wiki has some help about this: > http://www.emacswiki.org/emacs/LearningEmacs#LearnEmacsLisp > > I would also recommend this: > > Think of something simple that you would like to make Emacs do, and try to do > it. In particular, try to modify some existing Lisp function or command in some > way that you're interested in. > > This will get you to look at how things are done in the existing code, which is > a great source for models. And the existing code works (!), so any departures > you make from it can be compared when your changes don't do exactly what you > expect. > > Another help is to get familiar with an Emacs-Lisp debugger - either edebug or > the classic debugger (`debug-on-entry', put (debug) calls in your code, etc.). > Likewise, functions `message', `sit-for', and `sleep-for' (for use with > `message'). He's not popular with some on the more established Emacs users because of his outspokenness on the some of the more newbie unfriendly aspects of Emacs, but Xah Lee is an excellent resource with carefully argued points and practical approach to, amongst other things, eLisp usage :-; http://xahlee.org/emacs/elisp.html It is a learn by doing approach and might work well for you regards Richard. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 18:27 ` learning Emacs Lisp Richard Riley @ 2008-11-10 19:22 ` Tassilo Horn 2008-11-10 19:48 ` Drew Adams [not found] ` <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org> 1 sibling, 1 reply; 25+ messages in thread From: Tassilo Horn @ 2008-11-10 19:22 UTC (permalink / raw) To: help-gnu-emacs Richard Riley <rileyrgdev@gmail.com> writes: Hi Richard, > [...] but Xah Lee is an excellent resource with carefully argued > points and practical approach to, amongst other things, eLisp usage. This is a joke, isn't it? When learning a language it's better to take a look at polished code that uses this language's idioms. Xah's on a crusade against even the most basic stuff like correct indentation... The best resources for elisp are (info "(eintr)Top") and (info "(elisp)Top") together with the online help (`C-h ?'). All of these are included in emacs. And of course, you learn a language best by speaking/programming in it. But Drew already said that. Ah, and there's this (and other emacs related newsgroups) + #emacs on freenode where you can ask your questions. Bye, Tassilo -- A child of five could understand this! Fetch me a child of five! ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: learning Emacs Lisp 2008-11-10 19:22 ` Tassilo Horn @ 2008-11-10 19:48 ` Drew Adams 0 siblings, 0 replies; 25+ messages in thread From: Drew Adams @ 2008-11-10 19:48 UTC (permalink / raw) To: 'Tassilo Horn', help-gnu-emacs > The best resources for elisp are > (info "(eintr)Top") and (info "(elisp)Top") > together with the online help (`C-h ?'). Yes! Here's something to keep in mind. Lisp is a bit peculiar wrt things such as data structures and variables. Do yourself a favor and learn about things such as lists (list structure) and symbols from the above-mentioned sources or from other texts specifically about Lisp. Do not try to learn about such things from loose analogies with other languages, especially from writers who might not be all that Lispian. I'm not trying to denigrate any given text that tries to help you learn. I'm just saying beware of being misled by writings that tell you that symbols are variables or are like variables, or that Lisp passes arguments by value or reference or whatever - and so forth. Learn Lisp as Lisp, not wearing C or Java or Haskell glasses. Learn about symbols and conses and quote. Then go forth and cons. The Emacs-Lisp Intro mentioned above is definitely the place to start, as well as the first few chapters of the Elisp manual. Any book about Lisp is also bound to help, in spite of the fact that each Lisp dialect is a bit different. What's important is to grasp the basics of Lisp itself. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org>]
* Re: learning Emacs Lisp [not found] ` <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org> @ 2008-11-10 19:36 ` Richard Riley 2008-11-10 20:59 ` Niels Giesen 2008-11-11 4:56 ` Andreas Politz 0 siblings, 2 replies; 25+ messages in thread From: Richard Riley @ 2008-11-10 19:36 UTC (permalink / raw) To: help-gnu-emacs Tassilo Horn <tassilo@member.fsf.org> writes: > Richard Riley <rileyrgdev@gmail.com> writes: > > Hi Richard, > >> [...] but Xah Lee is an excellent resource with carefully argued >> points and practical approach to, amongst other things, eLisp usage. > > This is a joke, isn't it? Not in the slightest. I can only assume the bit you snipped about some more established Emacs users disagreeing with him applies to you? Or the tone suggests that. > > When learning a language it's better to take a look at polished code > that uses this language's idioms. Xah's on a crusade against even the > most basic stuff like correct indentation... By correct indentation I guess you mean the established custom? I cant disagree that customs are good but personally I think the established custom in elisp is rather awkward to the extreme. Not that i dont try to adhere to it :-; But even looking around the C world we see various indentation standards and everyone is entitled to their view. A constant style is, of course, better for everyone although it does not immediately mean that constant style is the best. As a programmer for years I can not even begin to understand how and why eLisp bracketing standards became as they did other than maybe to save screen real estate in the VT100 type days. FWIW, I think saving space is better for the eye too in some ways but I find "at a glance" analysis of most eLisp code almost impossible because of the standard of grouping all closing brackets. > > The best resources for elisp are > > (info "(eintr)Top") > > and > > (info "(elisp)Top") For eLisp reference maybe. But I found Xah Lee's tutorial very good. Its a programmers introduction and gets to the key points quickly in an ordered manner and grouped in logical sections. *shrug* We all prefer different methods. But I like his practical learn by doing approach. > > together with the online help (`C-h ?'). All of these are included in > emacs. If I might be so bold as to mention I added a context help addition which shows you the function or variable under point as an extension to eldoc: http://www.emacswiki.org/emacs-fr/ElDoc#toc6 > > And of course, you learn a language best by speaking/programming in it. > But Drew already said that. Of course. But eLisp is special in that its almost unreadable to the typical procedural programmer fluent in C/C++ etc until you know a lot if it already. Or that was my experience. And we all have different experiences so it does no harm to remain open as to what suits other people. I found Xah Lee's tutorial very useful and feel it would certainly benefit some others too. > > Ah, and there's this (and other emacs related newsgroups) + #emacs on > freenode where you can ask your questions. > > Bye, > Tassilo -- important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 19:36 ` Richard Riley @ 2008-11-10 20:59 ` Niels Giesen 2008-11-10 21:24 ` Richard Riley ` (2 more replies) 2008-11-11 4:56 ` Andreas Politz 1 sibling, 3 replies; 25+ messages in thread From: Niels Giesen @ 2008-11-10 20:59 UTC (permalink / raw) To: help-gnu-emacs Richard Riley <rileyrgdev@gmail.com> writes: [...] > Of course. But eLisp is special in that its almost unreadable to the > typical procedural programmer fluent in C/C++ etc until you know a lot > if it already. Or that was my experience. And we all have different > experiences so it does no harm to remain open as to what suits other > people. Where is there any evidence that the original OP is a `typical procedural programmer fluent in C/C++'? It annoys me to pieces that so many textbooks assume that everyone out there is a C/C++/Java programmer. For me, Lisp was my first programming language (thanks to Emacs, which I started using to write law papers in), and I do not need textbooks to explain for instance Ruby to me in Lisp (which is perfectly feasible) but I even less need comparisons with Java or C. Even worse, doing so is a major distraction from the real object of learning. Consider teaching Dutch to someone from Morocco but using English during the lessons: that's just plain silly and simply leads to unnecessary confusion. Using analogies from Slovak to teach Polish however may be insightful, but only when the student already has knowledge of a Slavic language. Same goes with programming languages: do not assume. When teaching something, teach it by itself; people willing to learn a new language are most likely not stupid, and if they are somewhat smart, they will find out for themselves what differences and similarities there are between languages known already. For me, it would have been nice when learning JavaScript if the books had warned me that not everything is an expression (invalid left-hand assignment anyone?), that you have to explicitly return something, that there are things such as keywords, and it would be nice if textbooks explain how to take advantage of closures instead of trying to get rid of them, hide them, and how to build an ugly half-assed Class system. The first few of those would cause people coming from C or Java at least to frown but most probably to get irritated ("Why would I care about all these strange incomprehensible things from some dead language with too many parens, when all I want to do is simply to learn JavaScript?????"). Therefore, I would not recommend such in a learning text on JavaScript. The second however, how to make good use of lexical scoping, is interesting to learn, and should be explained by itself, as should be prototype based inheritance and functions as first-class things (two of which could - but should not - be explained by comparison with Lisp). Comparisons with Java-style OOP however should not be in a basic textbook on learning JavaScript, and certainly no attempt should be made to mimic it -- for the very same reasons that comparisons with Lisp should not be made in a general textbook. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 20:59 ` Niels Giesen @ 2008-11-10 21:24 ` Richard Riley 2008-11-11 4:07 ` Xah 2008-11-11 6:49 ` Wei Weng 2 siblings, 0 replies; 25+ messages in thread From: Richard Riley @ 2008-11-10 21:24 UTC (permalink / raw) To: help-gnu-emacs Niels Giesen <niels.giesen@gmail.com> writes: > Richard Riley <rileyrgdev@gmail.com> writes: > [...] >> Of course. But eLisp is special in that its almost unreadable to the >> typical procedural programmer fluent in C/C++ etc until you know a lot >> if it already. Or that was my experience. And we all have different >> experiences so it does no harm to remain open as to what suits other >> people. > > Where is there any evidence that the original OP is a `typical > procedural programmer fluent in C/C++'? There isn't any. Why do you ask? I am and I found Xah Lee's tutorial helpful. I didn't assume he was or wasn't. I just added the link to allow the OP to evaluate the usefulness himself. Since you seem to be quite sure I am doing a mis-service I think its only fair to defend myself and point something out - If you read the paragraph above I specifically say: ,---- | And we all have different experiences so it does no harm to remain open | as to what suits other people. `---- So I am somewhat surprised by your reading of my reply. > > It annoys me to pieces that so many textbooks assume that everyone out > there is a C/C++/Java programmer. For me, Lisp was my first It would me too. But I didn't and nothing I said indicated I did. Had he been though it might be useful. Others read this threads too following a Google. If Lisp was your first language great. There are many, many more where it won't be. eLisp is a minority language and people familiar with others will frequently be looking to learn a little. This is obvious from reading this group and the #emacs irc channel. > programming language (thanks to Emacs, which I started using to write > law papers in), and I do not need textbooks to explain for instance > Ruby to me in Lisp (which is perfectly feasible) but I even less need > comparisons with Java or C. Even worse, doing so is a major > distraction from the real object of learning. Yes, that is all really nice. But others might benefit from the link. You seem quite adamant that it should not have been posted. I can not begin to think why. It is another eLisp resource that people MIGHT find useful depending on their skill levels, background and needs. Let them decide. > > Consider teaching Dutch to someone from Morocco but using English > during the lessons: that's just plain silly and simply leads to > unnecessary confusion. Using analogies from Slovak to teach Polish > however may be insightful, but only when the student already has > knowledge of a Slavic language. Same goes with programming languages: > do not assume. I don't. But I also don't decide for the person asking. Providing the link can do no harm. Ir is often forgotten that SOME programmers are looking for a quick and dirty introduction in order to do one thing and one thing only. They have neither the time, resources nor desire to learn something like Lisp from the bottom up and some readily available patterns and programming snippets are more than enough. i can only state once more : I personally found Xah Lee's tutorial useful and consider that others might too. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 20:59 ` Niels Giesen 2008-11-10 21:24 ` Richard Riley @ 2008-11-11 4:07 ` Xah 2008-11-12 0:24 ` B. T. Raven 2008-11-11 6:49 ` Wei Weng 2 siblings, 1 reply; 25+ messages in thread From: Xah @ 2008-11-11 4:07 UTC (permalink / raw) To: help-gnu-emacs On Nov 10, 12:59 pm, Niels Giesen <niels.gie...@gmail.com> wrote: > Richard Riley <rileyrg...@gmail.com> writes: > > [...] > > > Of course. But eLisp is special in that its almost unreadable to the > > typical procedural programmer fluent in C/C++ etc until you know a lot > > if it already. Or that was my experience. And we all have different > > experiences so it does no harm to remain open as to what suits other > > people. > > Where is there any evidence that the original OP is a `typical > procedural programmer fluent in C/C++'? Vast majority of programers coming to emacs is familiar with procedural languages, such as C, C++, Java, perl, php, visual basic. The original poster may be a exception, but it is reasonable to make a general assumption when giving tips. > It annoys me to pieces that so many textbooks assume that everyone out > there is a C/C++/Java programmer. For me, Lisp was my first > programming language (thanks to Emacs, which I started using to write > law papers in), and I do not need textbooks to explain for instance > Ruby to me in Lisp (which is perfectly feasible) but I even less need > comparisons with Java or C. Even worse, doing so is a major > distraction from the real object of learning. > > Consider teaching Dutch to someone from Morocco but using English > during the lessons: that's just plain silly and simply leads to > unnecessary confusion. Using analogies from Slovak to teach Polish > however may be insightful, but only when the student already has > knowledge of a Slavic language. Same goes with programming languages: > do not assume. it is relevant to consider something vast majority of readers are already familiar of. Vast majority of programers, are familiar with one of procedural lang such as C, Java, C++, perl, visual basic. These are roughly maybe 95% of all programers. So, when teaching a new programing language, mentioning tips related to procedural lang is fruitful and effective. Similarly, when teaching a foreign lang, it makes sense to mention tips contrasting to the lang English. > When teaching something, teach it by itself; people willing to learn a > new language are most likely not stupid, and if they are somewhat > smart, they will find out for themselves what differences and > similarities there are between languages known already. you are of course just bitching. Of course, most tutorials do try to teach the lang itself, and very few are entirely based on transition from another lang, such as “Python for Perl programers” or “Java for C+ + programers”, “PHP for Perl programers”, “Haskell for Lispers”, etc. > For me, it would have been nice when learning JavaScript if the books > had warned me that not everything is an expression (invalid left-hand > assignment anyone?), that you have to explicitly return something, > that there are things such as keywords, and it would be nice if > textbooks explain how to take advantage of closures instead of trying > to get rid of them, hide them, and how to build an ugly half-assed > Class system. > > The first few of those would cause people coming from C or Java at > least to frown but most probably to get irritated ("Why would I care > about all these strange incomprehensible things from some dead > language with too many parens, when all I want to do is simply to > learn JavaScript?????"). Therefore, I would not recommend such in a > learning text on JavaScript. You were complaining about books giving tips of procedural lang tips. But now you are using a example of giving tips about lisp to illustrate how silly it is. Note that the books we are discussing, do not give tips about lisp, because it is a lang very few people know. However, books about functional langs do sometimes give relevant info for programers familiar with lisp. The principle is the same, namely, that for a significant portion of the readership, they are familiar with lang x, so the book give tips for lang x programers. For example, the official elisp reference gives many tips and warnings to those familiar with Common Lisp, and about C too. (to me, it is entirely distracting because i do not have working familiarity with Common Lisp or C, nor do i care about them. However, i'm the world's top expert in Mathematica, but vast majority of potential readers of elisp doc are not familiar with Mathematica.) Similarly, Perl doc or books often contain tips, warnings, about C, awk, unix shell. Books on regex will often give tips or mention about Perl lang's regex. All in all, these tips mentioning another lang is useful. They are useful because learning is faster when we can borrow knowledge from somethnig we already know. In summary, when a programing lang x book gives tips for lang y programers, it is because a significant portion of its potential readers are familiar with lang y, therefore the tips is effective. ----------------- There are other extremes. For example, some books do not mention any other lang for tips or comparison at all. Examples include Mathematica's doc (The Mathematica Book), Java Doc (so-called the “Java API” Java™2 Platform Standard Edition 5.0 API Specification), Java Lang Spec, Scheme's r4rs. Typically, these are lang spec or official reference. On the other extreme, some books gets abusive in mentioning lots other langs instead of a proper description of the lang itself, often to the degree of making the doc itself unclear, confusing, or less useful. Example of this is Perl's doc (perldoc), Python doc. Typically, tutorial type of books tends to mention other langs, and some of them to a degree that's more damaging then helpful. As a example of the abusive use of mentioning other lang, here's a excerpt from Python doc on it's chapter about Python's class. It start thus: « Python's class mechanism adds classes to the language with a minimum of new syntax and semantics. It is a mixture of the class mechanisms found in C++ and Modula-3. As is true for modules, classes in Python do not put an absolute barrier between definition and user, but rather rely on the politeness of the user not to ``break into the definition.'' The most important features of classes are retained with full power, however: the class inheritance mechanism allows multiple base classes, a derived class can override any methods of its base class or classes, a method can call the method of a base class with the same name. Objects can contain an arbitrary amount of private data. In C++ terminology, all class members (including the data members) are public, and all member functions are virtual. There are no special constructors or destructors. As in Modula-3, there are no shorthands for referencing the object's members from its methods: the method function is declared with an explicit first argument representing the object, which is provided implicitly by the call. As in Smalltalk, classes themselves are objects, albeit in the wider sense of the word: in Python, all data types are objects. This provides semantics for importing and renaming. Unlike C++ and Modula-3, built-in types can be used as base classes for extension by the user. Also, like in C++ but unlike in Modula-3, most built-in operators with special syntax (arithmetic operators, subscripting etc.) can be redefined for class instances. » It is a form of author masterbation. In the case of Perl's official doc (perldoc), the workings of unix shell, awk, C is frequently mentioned in the doc as a way of explanation, just about every page on every function, instead of proper documentation independent of other langs. (partly for this reason, learning perl is difficult for those not from the unix/c background) The only perl book that properly discuss perl without borrowing other langs is “Perl: The Programmer's Companion” (1997) by Nigel Chapman. Similarly, unix docs (the “man pages”) are also like like. Instead of proper spec of what a function or tool do, it is written in a way that assumes you know C and much of the workings of unix, and mentions them throughout in a confusing way. For much more discussion about documentation, see: • Python Documentation Problems http://xahlee.org/perl-python/python_doc_index.html (collection of 11 essays on python documentation problems, and on documentation in general) • survey of perl books http://xahlee.org/UnixResource_dir/perlr.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 4:07 ` Xah @ 2008-11-12 0:24 ` B. T. Raven 2008-11-12 3:32 ` Xah 0 siblings, 1 reply; 25+ messages in thread From: B. T. Raven @ 2008-11-12 0:24 UTC (permalink / raw) To: help-gnu-emacs Xah wrote: > On Nov 10, 12:59 pm, Niels Giesen <niels.gie...@gmail.com> wrote: >> Richard Riley <rileyrg...@gmail.com> writes: >> >> [...] >> >>> Of course. But eLisp is special in that its almost unreadable to the >>> typical procedural programmer fluent in C/C++ etc until you know a lot >>> if it already. Or that was my experience. And we all have different >>> experiences so it does no harm to remain open as to what suits other >>> people. >> Where is there any evidence that the original OP is a `typical >> procedural programmer fluent in C/C++'? > > Vast majority of programers coming to emacs is familiar with > procedural languages, such as C, C++, Java, perl, php, visual basic. > > The original poster may be a exception, but it is reasonable to make a > general assumption when giving tips. > >> It annoys me to pieces that so many textbooks assume that everyone out >> there is a C/C++/Java programmer. For me, Lisp was my first >> programming language (thanks to Emacs, which I started using to write >> law papers in), and I do not need textbooks to explain for instance >> Ruby to me in Lisp (which is perfectly feasible) but I even less need >> comparisons with Java or C. Even worse, doing so is a major >> distraction from the real object of learning. >> >> Consider teaching Dutch to someone from Morocco but using English >> during the lessons: that's just plain silly and simply leads to >> unnecessary confusion. Using analogies from Slovak to teach Polish >> however may be insightful, but only when the student already has >> knowledge of a Slavic language. Same goes with programming languages: >> do not assume. > > it is relevant to consider something vast majority of readers are > already familiar of. > > Vast majority of programers, are familiar with one of procedural lang > such as C, Java, C++, perl, visual basic. These are roughly maybe 95% > of all programers. So, when teaching a new programing language, > mentioning tips related to procedural lang is fruitful and effective. > > Similarly, when teaching a foreign lang, it makes sense to mention > tips contrasting to the lang English. > >> When teaching something, teach it by itself; people willing to learn a >> new language are most likely not stupid, and if they are somewhat >> smart, they will find out for themselves what differences and >> similarities there are between languages known already. > > you are of course just bitching. Of course, most tutorials do try to > teach the lang itself, and very few are entirely based on transition > from another lang, such as “Python for Perl programers” or “Java for C+ > + programers”, “PHP for Perl programers”, “Haskell for Lispers”, etc. > >> For me, it would have been nice when learning JavaScript if the books >> had warned me that not everything is an expression (invalid left-hand >> assignment anyone?), that you have to explicitly return something, >> that there are things such as keywords, and it would be nice if >> textbooks explain how to take advantage of closures instead of trying >> to get rid of them, hide them, and how to build an ugly half-assed >> Class system. >> >> The first few of those would cause people coming from C or Java at >> least to frown but most probably to get irritated ("Why would I care >> about all these strange incomprehensible things from some dead >> language with too many parens, when all I want to do is simply to >> learn JavaScript?????"). Therefore, I would not recommend such in a >> learning text on JavaScript. > > You were complaining about books giving tips of procedural lang tips. > But now you are using a example of giving tips about lisp to > illustrate how silly it is. Note that the books we are discussing, do > not give tips about lisp, because it is a lang very few people know. > > However, books about functional langs do sometimes give relevant info > for programers familiar with lisp. The principle is the same, namely, > that for a significant portion of the readership, they are familiar > with lang x, so the book give tips for lang x programers. For example, > the official elisp reference gives many tips and warnings to those > familiar with Common Lisp, and about C too. > > (to me, it is entirely distracting because i do not have working > familiarity with Common Lisp or C, nor do i care about them. However, > i'm the world's top expert in Mathematica, but vast majority of > potential readers of elisp doc are not familiar with Mathematica.) I thought that Stephen Wolfram (author of _A New Kind of Science_) was the top expert. Is this another exaggeration like the statistics you pull out of a hat?: e.g. "99.9999% of all southpaws are touch typists." Remember that all majorities are not "vast," in fact the vast majority of them are not even majorities but only pluralities. Ed ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-12 0:24 ` B. T. Raven @ 2008-11-12 3:32 ` Xah 0 siblings, 0 replies; 25+ messages in thread From: Xah @ 2008-11-12 3:32 UTC (permalink / raw) To: help-gnu-emacs Xah Lee wrote: > > (to me, it is entirely distracting because i do not have working > > familiarity with Common Lisp or C, nor do i care about them. However, > > i'm the world's top expert in Mathematica, but vast majority of > > potential readers of elisp doc are not familiar with Mathematica.) B. T. Raven wrote: > I thought that Stephen Wolfram (author of _A New Kind of Science_) was > the top expert. Yes, he's one of the top expert in programing Mathematica. > Is this another exaggeration like the statistics you > pull out of a hat?: e.g. "99.9999% of all southpaws are touch typists." did u pull that out of a hat? > Remember that all majorities are not "vast," in fact the vast majority > of them are not even majorities but only pluralities. pluralities? how about multitudality? News: Xah discovered that multitudality of tech geekers are idiotic when it comes to critical thinking. can you try the command-frequency.el and let me know your results? because recently someone made it into a full featured minor mode and it's now very easy to use. It also saves between emacs restart. bottom: http://xahlee.org/emacs/command-frequency.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 20:59 ` Niels Giesen 2008-11-10 21:24 ` Richard Riley 2008-11-11 4:07 ` Xah @ 2008-11-11 6:49 ` Wei Weng 2008-11-11 18:58 ` Niels Giesen 2 siblings, 1 reply; 25+ messages in thread From: Wei Weng @ 2008-11-11 6:49 UTC (permalink / raw) To: help-gnu-emacs Niels Giesen wrote: > Richard Riley <rileyrgdev@gmail.com> writes: > [...] >> Of course. But eLisp is special in that its almost unreadable to the >> typical procedural programmer fluent in C/C++ etc until you know a lot >> if it already. Or that was my experience. And we all have different >> experiences so it does no harm to remain open as to what suits other >> people. > > Where is there any evidence that the original OP is a `typical > procedural programmer fluent in C/C++'? > > It annoys me to pieces that so many textbooks assume that everyone out > there is a C/C++/Java programmer. For me, Lisp was my first > programming language (thanks to Emacs, which I started using to write > law papers in), and I do not need textbooks to explain for instance > Ruby to me in Lisp (which is perfectly feasible) but I even less need > comparisons with Java or C. Even worse, doing so is a major > distraction from the real object of learning. > > Consider teaching Dutch to someone from Morocco but using English > during the lessons: that's just plain silly and simply leads to > unnecessary confusion. Using analogies from Slovak to teach Polish > however may be insightful, but only when the student already has > knowledge of a Slavic language. Same goes with programming languages: > do not assume. > > When teaching something, teach it by itself; people willing to learn a > new language are most likely not stupid, and if they are somewhat > smart, they will find out for themselves what differences and > similarities there are between languages known already. > > For me, it would have been nice when learning JavaScript if the books > had warned me that not everything is an expression (invalid left-hand > assignment anyone?), that you have to explicitly return something, > that there are things such as keywords, and it would be nice if > textbooks explain how to take advantage of closures instead of trying > to get rid of them, hide them, and how to build an ugly half-assed > Class system. > > The first few of those would cause people coming from C or Java at > least to frown but most probably to get irritated ("Why would I care > about all these strange incomprehensible things from some dead > language with too many parens, when all I want to do is simply to > learn JavaScript?????"). Therefore, I would not recommend such in a > learning text on JavaScript. > > The second however, how to make good use of lexical scoping, is > interesting to learn, and should be explained by itself, as should be > prototype based inheritance and functions as first-class things (two > of which could - but should not - be explained by comparison with > Lisp). > > Comparisons with Java-style OOP however should not be in a basic > textbook on learning JavaScript, and certainly no attempt should be > made to mimic it -- for the very same reasons that comparisons with > Lisp should not be made in a general textbook. This is a very typical case of "Too many words, too few substances". You spent all these time typing out all these words, I can summarize in 1 line: Elisp is very different from C/C++/Java, and it is my (Niels) first language. Thanks Wei ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 6:49 ` Wei Weng @ 2008-11-11 18:58 ` Niels Giesen 0 siblings, 0 replies; 25+ messages in thread From: Niels Giesen @ 2008-11-11 18:58 UTC (permalink / raw) To: help-gnu-emacs Reply to all First of all I'd like to say I do not think Xah's tutorial is in the category of texts I described. It is a fine introduction and teaches by example, by explaining in plain English the set goals and in Lisp the ways to achieve. The link to his tutorial is fine with me. Xah get's it right /not/ to draw on knowledge of other languages and it is no use advertising his tutorial as being suitable for average C&c programmers (which it sure may be, but other people can be scared away from it precisely because of that). Which is what I read in Richards post, but I may be reading too much between the lines there. I might have read the original message by Richard better, and admit having jumped at the 'average C/C++ programmer' bit. This comes from my perceived habit of writers assuming working knowledge in Y, and not properly advertising it as 'X for Yniks', while all the reader wants is to learn X. I thought this was such a case. Apparently not. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-10 19:36 ` Richard Riley 2008-11-10 20:59 ` Niels Giesen @ 2008-11-11 4:56 ` Andreas Politz 2008-11-11 8:48 ` Richard Riley 1 sibling, 1 reply; 25+ messages in thread From: Andreas Politz @ 2008-11-11 4:56 UTC (permalink / raw) To: help-gnu-emacs Richard Riley wrote: > Tassilo Horn <tassilo@member.fsf.org> writes: > >> Richard Riley <rileyrgdev@gmail.com> writes: >> >> Hi Richard, >> >>> [...] but Xah Lee is an excellent resource with carefully argued >>> points and practical approach to, amongst other things, eLisp usage. >> This is a joke, isn't it? > > Not in the slightest. I can only assume the bit you snipped about some > more established Emacs users disagreeing with him applies to you? Or the > tone suggests that. > >> When learning a language it's better to take a look at polished code >> that uses this language's idioms. Xah's on a crusade against even the >> most basic stuff like correct indentation... > > By correct indentation I guess you mean the established custom? I cant > disagree that customs are good but personally I think the established > custom in elisp is rather awkward to the extreme. Not that i dont try to > adhere to it :-; But even looking around the C world we see various > indentation standards and everyone is entitled to their view. A constant > style is, of course, better for everyone although it does not > immediately mean that constant style is the best. As a programmer for > years I can not even begin to understand how and why eLisp bracketing > standards became as they did other than maybe to save screen real estate > in the VT100 type days. FWIW, I think saving space is better for the eye > too in some ways but I find "at a glance" analysis of most eLisp code > almost impossible because of the standard of grouping all closing > brackets. > That darn old emacs again ! Seriously this has more to do with lisp in general than specifically with elisp. I doubt you'd find any _one_ serious programmer or author in the whole lisp community who proposes this kind of style ( each closing paren on a seperate line ). -ap >> The best resources for elisp are >> >> (info "(eintr)Top") >> >> and >> >> (info "(elisp)Top") > > For eLisp reference maybe. But I found Xah Lee's tutorial very > good. Its a programmers introduction and gets to the key points quickly > in an ordered manner and grouped in logical sections. > > *shrug* > > We all prefer different methods. But I like his practical learn by doing > approach. > >> together with the online help (`C-h ?'). All of these are included in >> emacs. > > If I might be so bold as to mention I added a context help addition which > shows you the function or variable under point as an extension to eldoc: > > http://www.emacswiki.org/emacs-fr/ElDoc#toc6 > >> And of course, you learn a language best by speaking/programming in it. >> But Drew already said that. > > Of course. But eLisp is special in that its almost unreadable to the > typical procedural programmer fluent in C/C++ etc until you know a lot > if it already. Or that was my experience. And we all have different > experiences so it does no harm to remain open as to what suits other > people. > > I found Xah Lee's tutorial very useful and feel it would certainly > benefit some others too. > >> Ah, and there's this (and other emacs related newsgroups) + #emacs on >> freenode where you can ask your questions. >> >> Bye, >> Tassilo > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 4:56 ` Andreas Politz @ 2008-11-11 8:48 ` Richard Riley 2008-11-11 9:57 ` Andreas Politz ` (3 more replies) 0 siblings, 4 replies; 25+ messages in thread From: Richard Riley @ 2008-11-11 8:48 UTC (permalink / raw) To: help-gnu-emacs Andreas Politz <politza@fh-trier.de> writes: > Richard Riley wrote: >> Tassilo Horn <tassilo@member.fsf.org> writes: >> >>> Richard Riley <rileyrgdev@gmail.com> writes: >>> >>> Hi Richard, >>> >>>> [...] but Xah Lee is an excellent resource with carefully argued >>>> points and practical approach to, amongst other things, eLisp usage. >>> This is a joke, isn't it? >> >> Not in the slightest. I can only assume the bit you snipped about some >> more established Emacs users disagreeing with him applies to you? Or the >> tone suggests that. >> >>> When learning a language it's better to take a look at polished code >>> that uses this language's idioms. Xah's on a crusade against even the >>> most basic stuff like correct indentation... >> >> By correct indentation I guess you mean the established custom? I cant >> disagree that customs are good but personally I think the established >> custom in elisp is rather awkward to the extreme. Not that i dont try to >> adhere to it :-; But even looking around the C world we see various >> indentation standards and everyone is entitled to their view. A constant >> style is, of course, better for everyone although it does not >> immediately mean that constant style is the best. As a programmer for >> years I can not even begin to understand how and why eLisp bracketing >> standards became as they did other than maybe to save screen real estate >> in the VT100 type days. FWIW, I think saving space is better for the eye >> too in some ways but I find "at a glance" analysis of most eLisp code >> almost impossible because of the standard of grouping all closing >> brackets. >> > > That darn old emacs again ! Seriously this has more to do with lisp in > general than specifically with elisp. I doubt you'd find any _one_ serious > programmer or author in the whole lisp community who proposes this kind of > style ( each closing paren on a seperate line ). You will notice that I did not propose it. I said the standard is hard for me to read as someone who is not an eLisp magician. I still do not understand (other than the reasons I postulated about above) why it is as it is. I find it very hard to indent and match (ok, emacs helps with matching brackets), but would find it very difficult to read from a printout for example. But this is more my lack of experience possibly. All hindrances can become less so with experience. But would aligned brackets really hurt anyone? I dont think so. It is convention (and convention is a good thing at times) which has the style as it is. Or? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 8:48 ` Richard Riley @ 2008-11-11 9:57 ` Andreas Politz 2008-11-11 10:14 ` Lennart Borgman ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Andreas Politz @ 2008-11-11 9:57 UTC (permalink / raw) To: help-gnu-emacs Richard Riley wrote: > Andreas Politz <politza@fh-trier.de> writes: > >> Richard Riley wrote: >>> Tassilo Horn <tassilo@member.fsf.org> writes: >>> >>>> Richard Riley <rileyrgdev@gmail.com> writes: >>>> >>>> Hi Richard, >>>> >>>>> [...] but Xah Lee is an excellent resource with carefully argued >>>>> points and practical approach to, amongst other things, eLisp usage. >>>> This is a joke, isn't it? >>> Not in the slightest. I can only assume the bit you snipped about some >>> more established Emacs users disagreeing with him applies to you? Or the >>> tone suggests that. >>> >>>> When learning a language it's better to take a look at polished code >>>> that uses this language's idioms. Xah's on a crusade against even the >>>> most basic stuff like correct indentation... >>> By correct indentation I guess you mean the established custom? I cant >>> disagree that customs are good but personally I think the established >>> custom in elisp is rather awkward to the extreme. Not that i dont try to >>> adhere to it :-; But even looking around the C world we see various >>> indentation standards and everyone is entitled to their view. A constant >>> style is, of course, better for everyone although it does not >>> immediately mean that constant style is the best. As a programmer for >>> years I can not even begin to understand how and why eLisp bracketing >>> standards became as they did other than maybe to save screen real estate >>> in the VT100 type days. FWIW, I think saving space is better for the eye >>> too in some ways but I find "at a glance" analysis of most eLisp code >>> almost impossible because of the standard of grouping all closing >>> brackets. >>> >> That darn old emacs again ! Seriously this has more to do with lisp in >> general than specifically with elisp. I doubt you'd find any _one_ serious >> programmer or author in the whole lisp community who proposes this kind of >> style ( each closing paren on a seperate line ). > > You will notice that I did not propose it. I said the standard is hard > for me to read as someone who is not an eLisp magician. Yes, I misunderstood you. I thought you were impying this, by the comparison with C. -ap I still do not > understand (other than the reasons I postulated about above) why it is > as it is. I find it very hard to indent and match (ok, emacs helps with > matching brackets), but would find it very difficult to read from a > printout for example. But this is more my lack of experience > possibly. All hindrances can become less so with experience. But would > aligned brackets really hurt anyone? I dont think so. It is convention > (and convention is a good thing at times) which has the style as it > is. Or? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 8:48 ` Richard Riley 2008-11-11 9:57 ` Andreas Politz @ 2008-11-11 10:14 ` Lennart Borgman [not found] ` <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org> 2008-11-11 10:43 ` Juanma Barranquero 3 siblings, 0 replies; 25+ messages in thread From: Lennart Borgman @ 2008-11-11 10:14 UTC (permalink / raw) To: Richard Riley; +Cc: help-gnu-emacs On Tue, Nov 11, 2008 at 9:48 AM, Richard Riley <rileyrgdev@gmail.com> wrote: >> That darn old emacs again ! Seriously this has more to do with lisp in >> general than specifically with elisp. I doubt you'd find any _one_ serious >> programmer or author in the whole lisp community who proposes this kind of >> style ( each closing paren on a seperate line ). > > You will notice that I did not propose it. I said the standard is hard > for me to read as someone who is not an eLisp magician. I still do not > understand (other than the reasons I postulated about above) why it is > as it is. I find it very hard to indent and match (ok, emacs helps with > matching brackets), but would find it very difficult to read from a > printout for example. But this is more my lack of experience > possibly. All hindrances can become less so with experience. But would > aligned brackets really hurt anyone? I dont think so. It is convention > (and convention is a good thing at times) which has the style as it > is. Or? I think that most elisp programmers will look at the indentation when reading the code on paper. You can compare with python where only the indentation matters. I do not like that, but the combination of indentation (for the eyes) and parenthesis (for the parser) seems very good to me. ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org>]
* Re: learning Emacs Lisp [not found] ` <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org> @ 2008-11-11 10:34 ` Richard Riley 0 siblings, 0 replies; 25+ messages in thread From: Richard Riley @ 2008-11-11 10:34 UTC (permalink / raw) To: help-gnu-emacs "Lennart Borgman" <lennart.borgman@gmail.com> writes: > On Tue, Nov 11, 2008 at 9:48 AM, Richard Riley <rileyrgdev@gmail.com> wrote: >>> That darn old emacs again ! Seriously this has more to do with lisp in >>> general than specifically with elisp. I doubt you'd find any _one_ serious >>> programmer or author in the whole lisp community who proposes this kind of >>> style ( each closing paren on a seperate line ). >> >> You will notice that I did not propose it. I said the standard is hard >> for me to read as someone who is not an eLisp magician. I still do not >> understand (other than the reasons I postulated about above) why it is >> as it is. I find it very hard to indent and match (ok, emacs helps with >> matching brackets), but would find it very difficult to read from a >> printout for example. But this is more my lack of experience >> possibly. All hindrances can become less so with experience. But would >> aligned brackets really hurt anyone? I dont think so. It is convention >> (and convention is a good thing at times) which has the style as it >> is. Or? > > I think that most elisp programmers will look at the indentation when > reading the code on paper. You can compare with python where only the > indentation matters. I do not like that, but the combination of > indentation (for the eyes) and parenthesis (for the parser) seems very > good to me. > While I am not surprised at some of the reactions to my recommendations for Xah Lee's tutorial, I feel I should defend it further from the perspective of the programmer coming to eLisp for the first time. I know for me going to php, , java, bash script and elisp (as some examples), I knew what I wanted to do. It was a question of how. I wanted to + display some stuff in the result are/log/status buffer + compare some values using standard operators + loop on things + define variables with varying scope + manipulate and merge some strings + create and use a function or two + handle arrays/lists of data and manipulate them If the following does not make that clear to a programmer then I think nothing will: http://xahlee.org/emacs/elisp_basics.html From that quick intro I could get into other people's code and read it a lot more comfortably. It reminds me very much of K&R's excellent tutorial section at the beginning of the C Programming language in that its written for the programmer who knows what he wants to do, just not in that particular language at that moment in time. I recommend it completely. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 8:48 ` Richard Riley ` (2 preceding siblings ...) [not found] ` <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org> @ 2008-11-11 10:43 ` Juanma Barranquero 2008-11-11 11:04 ` Richard Riley 3 siblings, 1 reply; 25+ messages in thread From: Juanma Barranquero @ 2008-11-11 10:43 UTC (permalink / raw) To: Richard Riley; +Cc: help-gnu-emacs On Tue, Nov 11, 2008 at 09:48, Richard Riley <rileyrgdev@gmail.com> wrote: > But would > aligned brackets really hurt anyone? I dont think so. Depend on your definition of "hurt". For many people, myself included, is ugly to the point of being almost unbearable. I suppose writing Pascal code like this if my_condition then begin { ... } end else begin { ... } end; or C code like this if (my_condition) { /*...*/ } else { /*...*/ } or worse: #define BEGIN { #define END } #define THEN #define ELSE else #define IF(c) if ((c)) IF(my_condition) THEN BEGIN /* ...*/ END ELSE BEGIN /*...*/ END doesn't really *hurt* anyone. But still... Juanma ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 10:43 ` Juanma Barranquero @ 2008-11-11 11:04 ` Richard Riley 2008-11-11 11:17 ` Juanma Barranquero 0 siblings, 1 reply; 25+ messages in thread From: Richard Riley @ 2008-11-11 11:04 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Richard Riley, help-gnu-emacs "Juanma Barranquero" <lekktu@gmail.com> writes: > On Tue, Nov 11, 2008 at 09:48, Richard Riley <rileyrgdev@gmail.com> wrote: > >> But would >> aligned brackets really hurt anyone? I dont think so. > > Depend on your definition of "hurt". For many people, myself included, > is ugly to the point of being almost unbearable. > > I suppose writing Pascal code like this > > if my_condition then begin > { ... } > end else begin > { ... } > end; I like the if(f){ /**/ }else{ /**/ } K&R style. Still, one man's meat is another man's poison. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: learning Emacs Lisp 2008-11-11 11:04 ` Richard Riley @ 2008-11-11 11:17 ` Juanma Barranquero 0 siblings, 0 replies; 25+ messages in thread From: Juanma Barranquero @ 2008-11-11 11:17 UTC (permalink / raw) To: Richard Riley; +Cc: Richard Riley, help-gnu-emacs On Tue, Nov 11, 2008 at 12:04, Richard Riley <rileyrgdev@googlemail.com> wrote: > I like the > > if(f){ > /**/ > }else{ > /**/ > } > > K&R style. I like it too, more or less, but the equivalent in Pascal is quite ugly IMO. But, as you say, that's K&R style, so it is widely known. Of course indentation styles are conventions; we find them ugly or beautiful, mostly, out of familiarity. And in the Lisp family of languages, aligned brackets are unusual, except in very deeply indented code; and even so, it's often not that brackets are aligned, as that a bunch of them are moved to the next line to avoid having too many closing parenthesis put together. > Still, one man's meat is another man's poison. Sure. Juanma ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: Grouping related buffers 2008-11-10 15:21 Grouping related buffers Corey Foote 2008-11-10 16:43 ` Tassilo Horn @ 2008-11-10 18:26 ` Drew Adams [not found] ` <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 25+ messages in thread From: Drew Adams @ 2008-11-10 18:26 UTC (permalink / raw) To: 'Corey Foote', help-gnu-emacs > I was wondering if there was a way to group related buffers > in Emacs through the use of, say, multiple buffer workspaces. > For example, it would be nice if when I display a list of > existing buffers by typing C-x C-b it would be possible to > group the buffers in the list, and when I called C-x b only > the buffers in the current grouping would be available. (To > get at the others it would be necessary to change the > current buffer workspace.) [Please use plain text, not HTML, for this mailing list.] There are probably several ways to do what you want. Look on Emacs Wiki, and perhaps take a look also at Ibuffer (dunno about that). Here is another. In Icicles, you can define any number of named buffer configurations. Each buffer config represents a named set of buffers, together with a sort function and other parameters that control buffer-name completion. * config name * regexp that buffer names must match * regexp that buffer names must not match * predicate that buffer names must satisfy * explicit list of additional buffers * buffer-name sort function For example, here is a buffer config named `Files and Scratch' that includes only buffer `*scratch*' and buffers visiting files. By default, the buffer names are sorted alphabetically. ("Files and Scratch" ; config name nil ; must-match regexp nil ; must-not-match regexp (lambda (bufname) ; predicate (buffer-file-name (get-buffer bufname))) ("*scratch*") ; extra buffers string-lessp) ; sort function See: http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects http://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-b uffer-configs Independently of any buffer configs, you can also save (persistently or not) any set of buffer-name completion candidates to reuse for completion later. (You can also save and then reuse file names or any other set of completion candidates.) See: http://www.emacswiki.org/emacs/Icicles_-_Candidate_Sets ^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org>]
* Re: Grouping related buffers [not found] ` <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org> @ 2008-11-13 13:09 ` Stefan Kamphausen 0 siblings, 0 replies; 25+ messages in thread From: Stefan Kamphausen @ 2008-11-13 13:09 UTC (permalink / raw) To: help-gnu-emacs Hi, Tassilo Horn <tassilo@member.fsf.org> writes: > Corey Foote <coreyfoote@hotmail.com> writes: > > Hi Corey! > >> I was wondering if there was a way to group related buffers in Emacs >> through the use of, say, multiple buffer workspaces. please excuse the self-plug but here it is nevertheless... I've written something like that for my own use: http://www.skamphausen.de/cgi-bin/ska/mtorus You can create a "ring of rings" where the inner rings are markers and the outer ring organizes the inner rings. Ah, complicated to explain, I already tried that in the comments of mtorus.el and failed. Maybe you just give it a try. Cheers, Stefan -- Stefan Kamphausen --- http://www.skamphausen.de a blessed +42 regexp of confusion (weapon in hand) You hit. The format string crumbles and turns to dust. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2008-11-13 13:09 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-11-10 15:21 Grouping related buffers Corey Foote 2008-11-10 16:43 ` Tassilo Horn 2008-11-10 17:24 ` Corey Foote 2008-11-10 18:05 ` learning Emacs Lisp [was: Grouping related buffers] Drew Adams [not found] ` <mailman.9.1226340315.26697.help-gnu-emacs@gnu.org> 2008-11-10 18:27 ` learning Emacs Lisp Richard Riley 2008-11-10 19:22 ` Tassilo Horn 2008-11-10 19:48 ` Drew Adams [not found] ` <mailman.17.1226345002.26697.help-gnu-emacs@gnu.org> 2008-11-10 19:36 ` Richard Riley 2008-11-10 20:59 ` Niels Giesen 2008-11-10 21:24 ` Richard Riley 2008-11-11 4:07 ` Xah 2008-11-12 0:24 ` B. T. Raven 2008-11-12 3:32 ` Xah 2008-11-11 6:49 ` Wei Weng 2008-11-11 18:58 ` Niels Giesen 2008-11-11 4:56 ` Andreas Politz 2008-11-11 8:48 ` Richard Riley 2008-11-11 9:57 ` Andreas Politz 2008-11-11 10:14 ` Lennart Borgman [not found] ` <mailman.58.1226398497.26697.help-gnu-emacs@gnu.org> 2008-11-11 10:34 ` Richard Riley 2008-11-11 10:43 ` Juanma Barranquero 2008-11-11 11:04 ` Richard Riley 2008-11-11 11:17 ` Juanma Barranquero 2008-11-10 18:26 ` Grouping related buffers Drew Adams [not found] ` <mailman.0.1226335408.26697.help-gnu-emacs@gnu.org> 2008-11-13 13:09 ` Stefan Kamphausen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.