From tcr at freebits.de Mon Jan 14 23:49:10 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Tue, 15 Jan 2008 00:49:10 +0100 (CET) Subject: [editor-hints-devel] Initial message to create gmane.lisp.editors.hints.devel group. Message-ID: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> Intentionally left unblank. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner From tcr at freebits.de Tue Jan 15 00:21:39 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Tue, 15 Jan 2008 01:21:39 +0100 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> Message-ID: <87sl10gcq4.fsf@freebits.de> "Tobias C. Rittweiler" writes: > Intentionally left unblank. "Achtung, hier herrscht Verr?cktheit!" -T. From gmane at cmm.kakpryg.net Thu Jan 17 13:18:57 2008 From: gmane at cmm.kakpryg.net (Michael Livshin) Date: Thu, 17 Jan 2008 15:18:57 +0200 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> Message-ID: <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> "Tobias C. Rittweiler" writes: > "Tobias C. Rittweiler" writes: > >> Intentionally left unblank. > > "Achtung, hier herrscht Verr?cktheit!" that said, some sort of an overall vision would be nice. :) cheers, --m From tcr at freebits.de Fri Jan 18 08:54:13 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Fri, 18 Jan 2008 09:54:13 +0100 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> Message-ID: <87k5m7ms3u.fsf@freebits.de> Michael Livshin writes: > that said, some sort of an overall vision would be nice. :) Lisp has traditionally been a very interactive language. Yet Common Lisp doesn't specify much with respect to interplay between language and (user) environment. The specification does contain a very humble Environment chapter that inclusion was supported by the standardization commitee to signal the message that environmental interactivity is wished for. Editor-hints is supposed to become an interface between the language Common Lisp and Lisp development environments. -T. P.S.: Its current TODO list looks as follows: * Named readtables: Create a namespace for readtable analogously to that of packages. `(IN-READTABLE :FOO)' are supposed to be recognized by editors, to properly deal with different readtables when evaluating stuff. * Indentation: Add a facility to specify how symbols are supposed to be indented. I.e. something like a DECLAIM-INDENTATION (being based upon a PROCLAIM-INDENTATION function) which store indentation information in some retrievable way. So that editors can rely on that information from a running Lisp image. This requires some research about the indentation specification schemes that different Lisp systems (Lisp machines, Symbolics' Genera, GNU Emacs, Lispworks, AllegroCL) use. And then define a practical denominator. * Documentation retrieval: Add the facility to support project-specific documentation retrieval on a per symbol basis. It's common that editors provide the possibility to quickly visit the respective CLHS site for a symbol. But this doesn't work on symbols not defined by ANSI. * Pretty docstrings: Add support for using markup in docstrings. Also detach too elaborate docstrings from the actual function/macro/&c definition. * Source locations: First class source locations; for instance imagine a (DEFINE-ELABORATE-DOCUMENTATION FOO ...) macro that registers documentation (in CLHS style, for example) to the symbol FOO, and which can be retrieved via (DOCUMENTATION 'FOO 'ELABORATE-DOCUMENTATION) Now, an editor may also want to provide M-.ness for this stuff, i.e. to enable the user to easily jump to the DEFINE-ELABORATE-DOCUMENTATION definition. For that to work, the above macro should expand to something that registers its source location into a a weak hash-table from symbols to source locations, such that the editor can consult that hash-table by some specified interface. From tcr at freebits.de Fri Jan 18 15:30:06 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Fri, 18 Jan 2008 16:30:06 +0100 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> <87k5m7ms3u.fsf@freebits.de> Message-ID: <873asv2ltt.fsf@freebits.de> "Tobias C. Rittweiler" writes: > Editor-hints is supposed to become an interface between the language > Common Lisp and Lisp development environments. I call this project to be successfull if its integration into Slime makes it popular enough to become a standard requirement of future Open Source Lisp projects. At least this is what I strive for. I hope that such popularity will make it rise on the radars of commercial Lisp environments. > Its current TODO list looks as follows: > > ... > > * Indentation: > > Add a facility to specify how symbols are supposed to be indented. > I.e. something like a DECLAIM-INDENTATION (being based upon a > PROCLAIM-INDENTATION function) which store indentation information > in some retrievable way. So that editors can rely on that > information from a running Lisp image. > > This requires some research about the indentation specification > schemes that different Lisp systems (Lisp machines, Symbolics' > Genera, GNU Emacs, Lispworks, AllegroCL) use. And then define > a practical denominator. Are you still interested in working on that, Michael? -T. From rpgoldman at sift.info Fri Jan 18 16:05:44 2008 From: rpgoldman at sift.info (Robert Goldman) Date: Fri, 18 Jan 2008 10:05:44 -0600 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. In-Reply-To: <87k5m7ms3u.fsf@freebits.de> References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> <87k5m7ms3u.fsf@freebits.de> Message-ID: <4790CE58.5080501@sift.info> Tobias C. Rittweiler wrote: [...] > > Its current TODO list looks as follows: > > > * Named readtables: > > Create a namespace for readtable analogously to that of packages. > > `(IN-READTABLE :FOO)' are supposed to be recognized by editors, > to properly deal with different readtables when evaluating stuff. I'd suggest that the editors be able to handle readtable specifications in the mode line, as well. Indeed, since the mode line is the directive to the editor, I'm inclined to think that the mode line should take precedence.... But I certainly haven't thought deeply about this.. > > * Indentation: > > Add a facility to specify how symbols are supposed to be indented. > I.e. something like a DECLAIM-INDENTATION (being based upon a > PROCLAIM-INDENTATION function) which store indentation information > in some retrievable way. So that editors can rely on that > information from a running Lisp image. > > This requires some research about the indentation specification > schemes that different Lisp systems (Lisp machines, Symbolics' > Genera, GNU Emacs, Lispworks, AllegroCL) use. And then define > a practical denominator. I don't believe that the Allegro CL environment actually has an indentation specification scheme. Allegro CL's environment, for me at least, is just Emacs (but I don't use Allegro Composer). So I think it will be easy for us to just handle emacs. > > * Documentation retrieval: > > Add the facility to support project-specific documentation > retrieval on a per symbol basis. > > It's common that editors provide the possibility to quickly visit > the respective CLHS site for a symbol. But this doesn't work on > symbols not defined by ANSI. > > * Pretty docstrings: > > Add support for using markup in docstrings. > > Also detach too elaborate docstrings from the actual > function/macro/&c definition. I like the idea of Markdown, since it's a syntax engineered for text readability and html-generation. I wanted to use Gary King's CL-markdown, but I wasn't willing to accept the chain of library dependencies (not to criticize Gary in particular, it's just that I don't ever use long chains of CL library dependencies). Best, R From rpgoldman at sift.info Fri Jan 18 16:12:34 2008 From: rpgoldman at sift.info (Robert Goldman) Date: Fri, 18 Jan 2008 10:12:34 -0600 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. In-Reply-To: <873asv2ltt.fsf@freebits.de> References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> <87k5m7ms3u.fsf@freebits.de> <873asv2ltt.fsf@freebits.de> Message-ID: <4790CFF2.6070001@sift.info> Tobias C. Rittweiler wrote: > "Tobias C. Rittweiler" writes: > >> Editor-hints is supposed to become an interface between the language >> Common Lisp and Lisp development environments. > > I call this project to be successfull if its integration into Slime > makes it popular enough to become a standard requirement of future > Open Source Lisp projects. At least this is what I strive for. I have not been able to wean myself from Allegro's ELI (I have too many lines of configuration code), so I'll try to make ELI-compatible equivalents of any SLIME code... Cheers, R From tcr at freebits.de Fri Jan 18 18:47:01 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Fri, 18 Jan 2008 19:47:01 +0100 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> <87k5m7ms3u.fsf@freebits.de> <4790CE58.5080501@sift.info> Message-ID: <87tzlb0y56.fsf@freebits.de> Robert Goldman writes: > Tobias C. Rittweiler wrote: > > > `(IN-READTABLE :FOO)' are supposed to be recognized by editors, > > to properly deal with different readtables when evaluating stuff. > > I'd suggest that the editors be able to handle readtable specifications > in the mode line, as well. Indeed, since the mode line is the directive > to the editor, I'm inclined to think that the mode line should take > precedence.... But I certainly haven't thought deeply about this.. Think of -*- Readtable: :FOO -*- (in-readtable :foo) ... (in-readtable :bar) ... (in-readtable :foo) Although not good style, this certainly should be made to work. So the value of File Variables should be a fall back, and the surrounding IN-READTABLE form should take precedence. -T. From gmane at cmm.kakpryg.net Sat Jan 19 07:29:19 2008 From: gmane at cmm.kakpryg.net (Michael Livshin) Date: Sat, 19 Jan 2008 09:29:19 +0200 Subject: [editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group. References: <45854.138.246.7.153.1200354550.squirrel@www.freebits.de> <87sl10gcq4.fsf@freebits.de> <87ejcg4mke.fsf@colinux.kakpryg.net.cmm> <87k5m7ms3u.fsf@freebits.de> <873asv2ltt.fsf@freebits.de> Message-ID: <87abn246k0.fsf@colinux.kakpryg.net.cmm> "Tobias C. Rittweiler" writes: > Are you still interested in working on that, Michael? yes, I think I am. (and, as Robert says, looks like the indentation hints need only support Emacs anyway, so there's not really that much to do on that front). cheers, --m From tcr at freebits.de Wed Jan 23 10:42:17 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Wed, 23 Jan 2008 11:42:17 +0100 Subject: [editor-hints-devel] Initial checkin. Message-ID: <87r6g8962e.fsf@freebits.de> Alright, RPG and me migrated the svn repository from his employer to common-lisp.net. You can fetch the sources via svn checkout svn://common-lisp.net/project/editor-hints/svn The sources contain so far only an almost complete implementation of named readtables. Incomplete only in so far that merging of readtables don't work so far, because it needs introspection into a readtable which the standard doesn't offer. I can implement this kind of introspection by shadowing SET-MACRO-CHARACTER &c. -- although I'd like implementations to provide this functionality themselves ultimativaly (think CDR.) Named Readtables provide a package like namespace for readtables. Every normal .lisp file should start with (in-package :foo) ; where # uses :EDITOR-HINTS (in-readtable :standard) You can define your own named readtables via DEFREADTABLE: (eval-when (:compile-toplevel :load-toplevel :execute) (defun semicolon-reader (stream char) (declare (ignore char)) (let ((comment-string (read-line stream nil "" t))) `(comment (string-left-trim '(#\; #\Space #\Tab) comment-string))))) (defreadtable :preserving-comments (:merge :standard) (:macro-char #\; #'semicolon-reader nil)) So you can now use (in-readtable :preserving-comments) And `;;; Foo Bar Quux' comments will be READ as (comment "Foo Bar Quux"). More so, other readtable definitions can now take use of this definition, too: (defreadtable :foobar (:merge :standard :preserving-comments) ...) [This kind of merging doesn't work currently.] -T. From luismbo at gmail.com Mon Jan 28 06:56:22 2008 From: luismbo at gmail.com (Luis Oliveira) Date: Mon, 28 Jan 2008 06:56:22 +0000 Subject: [editor-hints-devel] Comments about defreadtable Message-ID: Hello, Here are a few random thoughts with regard to defreadtable: 1. This mechanism seems useful enough to me that the non-editor-related bits could live in a separate package/system/project. 2. Readtables should be named by symbols, not strings, in order to avoid collisions between different code bases. Also, I suggest defreadtable should signal a warning (or a style-warning) if a CL or KEYWORD symbol is used to name a readtable. Again, the goal is to avoid collisions. 3. MAKE-DISPATCH-MACRO-CHARACTER functionality is missing. Perhaps the :DISPATCH-MACRO-CHAR directive can check for (null (get-macro-character macro-char)) and create that dispatch-macro, or maybe another directive would be better. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From rpgoldman at sift.info Mon Jan 28 15:26:20 2008 From: rpgoldman at sift.info (Robert P. Goldman) Date: Mon, 28 Jan 2008 09:26:20 -0600 Subject: [editor-hints-devel] Comments about defreadtable In-Reply-To: References: Message-ID: <479DF41C.3080502@sift.info> Luis Oliveira wrote: > Hello, > > Here are a few random thoughts with regard to defreadtable: > > 1. This mechanism seems useful enough to me that the > non-editor-related bits could live in a separate > package/system/project. Agreed. > > 2. Readtables should be named by symbols, not strings, in order to > avoid collisions between different code bases. Also, I suggest > defreadtable should signal a warning (or a style-warning) if a CL > or KEYWORD symbol is used to name a readtable. Again, the goal is > to avoid collisions. I don't actually agree with this point. Tobias has tried here to make readtables act like packages, and this change would destroy that commonality. It would also make the use of readtable specifiers in mode lines problematic. I actually think that having all package names share a single global namespace is not a desirable feature of CL, but it's not fixable by us, and I think the arguments for making readtables act like packages are strong. If the CL community is to manage to grow and deal with larger sets of libraries, we will have to evolve some kind of convention to avoid name collisions across packages, possibly something like the java package naming convention, foo.bar.bletch, and we should be able to extend that to readtable naming. > > 3. MAKE-DISPATCH-MACRO-CHARACTER functionality is missing. Perhaps > the :DISPATCH-MACRO-CHAR directive can check for > (null (get-macro-character macro-char)) and create that > dispatch-macro, or maybe another directive would be better. > This seems like a good idea. Best, R -- Robert P. Goldman Senior Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 384-3454 Email: rpgoldman at SIFT.info From luismbo at gmail.com Mon Jan 28 19:35:46 2008 From: luismbo at gmail.com (Luis Oliveira) Date: Mon, 28 Jan 2008 19:35:46 +0000 Subject: [editor-hints-devel] Re: Comments about defreadtable References: <479DF41C.3080502@sift.info> Message-ID: "Robert P. Goldman" writes: > Luis Oliveira wrote: [...] >> 2. Readtables should be named by symbols , not strings [...] > > I don't actually agree with this point. Tobias has tried here to make > readtables act like packages, and this change would destroy that > commonality. It would also make the use of readtable specifiers in mode > lines problematic. I've heard that argument before. It makes perfect sense to follow the feel of defpackage because we're dealing with similar mechanisms. I think that using strings to designate readtables might be pushing the metaphor a bit too far, though. I think it's somewhat obvious why package names aren't symbols, the circularity makes my brain hurt; it doesn't apply to readtables. How is it problematic for mode lines? > I actually think that having all package names share a single global > namespace is not a desirable feature of CL, but it's not fixable by us, Agreed, I have seen hacks that implement extra namespaces for packages. (E.g. in namespace foo, package names a, c and d map to packages x, y z.) So there is hope. :-) > and I think the arguments for making readtables act like packages are > strong. The only argument I've heard is "that's what defpackage does", which doesn't seem good enough to me. We wouldn't justify calling make-package instead of copy-readtable because that's what defpackage does would we? > If the CL community is to manage to grow and deal with larger sets of > libraries, we will have to evolve some kind of convention to avoid name > collisions across packages, possibly something like the java package > naming convention, foo.bar.bletch, and we should be able to extend that > to readtable naming. I think that supports my argument. If we name readtables using symbols now, we'll get those features for free later. -- Lu?s Oliveira http://student.dei.uc.pt/~lmoliv/ From rpgoldman at sift.info Mon Jan 28 23:42:39 2008 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 28 Jan 2008 17:42:39 -0600 Subject: [editor-hints-devel] Comments about defreadtable In-Reply-To: <391f79580801281102h7b2da196l84e94f79057e21e3@mail.gmail.com> References: <479DF41C.3080502@sift.info> <391f79580801281102h7b2da196l84e94f79057e21e3@mail.gmail.com> Message-ID: <479E686F.2030602@sift.info> Lu?s Oliveira wrote: > On 28/01/2008, Robert P. Goldman wrote: >>> 2. Readtables should be named by symbols, not strings, in order to >>> avoid collisions between different code bases. Also, I suggest >>> defreadtable should signal a warning (or a style-warning) if a CL >>> or KEYWORD symbol is used to name a readtable. Again, the goal is >>> to avoid collisions. >> I don't actually agree with this point. Tobias has tried here to make >> readtables act like packages, and this change would destroy that >> commonality. It would also make the use of readtable specifiers in mode >> lines problematic. > > I've heard that argument before. It makes perfect sense to follow the > feel of defpackage because we're dealing with similar mechanisms. I > think that using strings to designate readtables might be pushing the > metaphor a bit too far, though. I think it's somewhat obvious why > package names aren't symbols, the circularity makes my brain hurt; it > doesn't apply to readtables. Actually, I don't think it would be bad to have package names being symbols --- that would apply a modularity and scoping that we sorely lack in the package system. Given that we lack this in the package system, we must come up with a naming convention to overcome the lack. Since we have to do this, anyway, I'm inclined to suggest we just extend the same mechanism to readtables, to keep the parallelism. This is probably an aesthetic disagreement where neither of us will convince the other. I think that if we have to introduce foo.bar package names, we might as well have foo.bar readtable names. You find this disturbing. On the other hand, I find the idea of foo:bar readtable names disturbing, because it violates the package/readtable parallelism. I don't think either of these positions is clearly wrong. I don't agree with your position on the tradeoff, but I understand the rationale. We've each stated our position, I propose that whoever is excited enough about this to make it work should carry on from here with his/her own preference. FWIW, the starting motivation on my part was simply to provide SBCL and other lisps with compatibility with the ACL named-readtable facility. I didn't actually mean to step into such a large undertaking! So maybe this limited aspiration is a bias in my choice. > > How is it problematic for mode lines? I'm concerned that one may be opening the lisp file in emacs in a state in which the package is not available. If you are to start interpreting or compiling code in the file, of course, the package would have to be in place, but I'm concerned that the emacs+lisp ensemble might get confused if there's a period after the file is loaded into emacs and before the package-qualified symbol designator in the mode line becomes valid. Best, R From tcr at freebits.de Tue Jan 29 09:44:56 2008 From: tcr at freebits.de (Tobias C. Rittweiler) Date: Tue, 29 Jan 2008 10:44:56 +0100 Subject: [editor-hints-devel] Re: Comments about defreadtable References: Message-ID: <8763xdge3r.fsf@freebits.de> Luis Oliveira writes: > 1. This mechanism seems useful enough to me that the > non-editor-related bits could live in a separate > package/system/project. I don't want to make it its own project. I'm afraid it could belittle the (putative!) easy acceptance of the rest of Editor-hints. Rationale: People who're interested in named readtables are probably authors of libraries, and they /should/ also be interested in the other stuff that Editor-hints is going to provide (especially the documentation bits.) Furthermore, small projects do not necessarily correlate to more popularity: if you, for instance, look at Nikodemus Siivola's hyperdoc project. Which I'll revive by integrating it into Editor-hints. (An counter example would be split-sequence and cl-utilities. Most project simply depend on the split-sequence package rather than on cl-utilities which also contains split-sequence plus half a dozen other useful utilities.) Putting Named-Readtables into their own system is something I initially planned, but my ASDF-fu was too weak to get it working quickly, so I settled for just one system for now. (I'd like that simply linking the editor-hints.asd file is enough, and that this will take care of also implicitly registering named-readtables.) -T.