mac-lisp-ide

mac-lisp-ide@common-lisp.net

19 discussions

[mac-lisp-ide] Any updates?
by Daniel Dickison 23 Nov '05

23 Nov '05

I see that the last message in the archive is over a year old. Are there any developments in a native Mac Lisp IDE? I would very much like to help such an effort. Daniel

2 1

[mac-lisp-ide] Clotho status update
by Mikel Evins 08 Aug '04

08 Aug '04

Bosco 0.6.1 has been out for a few weeks, and bug reports are not pouring in. A tutorial on using it is now available at http://evins.net/bosco-howto/. Since completing the tutorial, I've been working on a new version of Clotho, the OpenMCL-based Lisp IDE for Mac OS X. Progress is incremental, but steady. The new application is Carbon-based, so that it won't be tied to such specific versions of Mac OS X. There is a known problem in current versions of OpenMCL such that binaries built on one version of OSX cannot run on an even slightly-different version of OSX. Carbon-based applications don't suffer this problem, so, at least for now, Clotho will be Carbon-based. As it mentions in the Bosco tutorial, you have to do more low-level work to get things happening in a Carbon application, so it's taking a while, but the new Clotho application is building and running, and it knows how to open TEXT documents, edit them, and save them (though it doesn't yet know how to open its own saved files! doh!). It feels very fast compared to earlier, Cocoa-based versions. The SLIME interface works, and it's possible to interact sensibly with the Lisp through that, but the running code won't really be very interesting until I get the Clotho listener hooked up again and finish the editor. I plan to wired up Alpaca-style key-bindings and APIs again. As a side-effect of building the application, an embryonic CLOS wrapper around the Carbon APIs is beginning slowly to emerge. I imagine the most generally-useful parts will migrate back into the next version of Bosco, pushing Bosco a little farther down the path from template to framework. That would be good. The least pleasing aspect of building Carbon apps in Lisp is the large number of times one must fail before getting the magic incantation of Carbon calls just right. Paul Lathrop reports further improvements to his project-building utilities; those will certainly go into the next version of Clotho, and I'm hoping I'll have time to make a dynamic UI-swapper, so that the next Clotho can load and display the contents of nibfiles, and maybe even let you hook up event handlers to them. We'll see. The long-term goal is to make it possible to load and test nib resources in Clotho and save them along with event-handling code into your project. I also plan to make a facility that runs the application build for you without needing to leave Clotho (beacuse of the way that save-application works, that will probably mean running a child process that does the build). Contributors are of course always welcome. If you want to get and build the new code, just check out the head of the cvs repository and build it, Bosco-like, from the root directory. You'll need OpenMCL 0.14.2. --me

1 0

[mac-lisp-ide] Portable Hemlock and questions
by David Steuber 23 Jul '04

23 Jul '04

These are just some idle questions. Is the source from Hemlock at all useful as far as editing functions for porting over to a proper Carbon based application for an Aqua compliant IDE? Are there any other independent projects besides Clotho in this area? Is the goal of this list to work on an implementation portable IDE (OpenMCL, SBCL, etc), or is a particular implementation favored? What about integration with Interface Builder? This is a very quiet list. Could it be that many people think Emacs + SLIME (or some other non-Aqua solution) is "good enough" for now? SLIME has done some clever stuff to support a wide variety of Lisp implementations. The techniques used in that project may be applicable for a portable implementation. How much extra work is that compared to just supporting a single implementation? Is there a current wish list / spec for this project?

3 3

[mac-lisp-ide] Thoughts on syntax editing
by Brian Mastenbrook 09 Jul '04

09 Jul '04

I've been thinking for several weeks about the issues involved with supporting syntax-aware editing in an editor, particularly Common Lisp syntax. Recently I wrote an incremental parser to handle syntax coloring for lisppaste, and so that experience has helped me to get a better handle on what the relevant issues are to supporting robust syntax-aware editing in a text editor. What I'm including in the umbrella of syntax-aware editing are the following tasks: * Coloring the source based on syntactic type * Detecting invalid syntax and (a) informing the user and (b) skipping over detectable sections of invalid syntax when performing other commands * Detecting sections of comment and strings, and ignoring these for other commands appropriately * and, commands which operate on the parse tree of the source, including the C-M-* functions which operate on an entire * s-expression There are several approaches to making this work. Two of them have been done before en masse, with various degrees of success: * Force the user to only edit valid syntax, and insert balanced pairs of parens / quotes / comment delimiters. This approach works fine for editing new source but does not work so well when reading in an existing, possibly invalid file, and also can feel much like a straightjacket. It also requires a large amount of adaptation to the environment. The best exemplar of this approach is Interlisp's S-Edit structural editor. * Maintain the view that the text is merely an octet stream, and locally use regexps to try to determine what syntax things are, setting character properties along the way. This approach is (as far as I understand it) the approach used by Emacs, which leads to massive confusion when editing unbalanced strings and comments. Sometimes Emacs never recovers; especially with CL-style #||# multiline comments. What I would like to see is a third path: a robust editor which always knows the syntactic type of the text, but allows the user to edit code as if they were using a plain text editor (or allows a slightly smarter mode where balanced syntax is inserted by default). This is the holy grail of useful syntactic editing. It's also very complicated. My first approach in writing such an editor revolved around viewing a buffer as a doubly-linked list of lines, which themselves were a doubly linked list composed of segments of text broken up by markers (which delineate syntactic type and also include the cursor and mark). This approach quickly got very complex: it was too difficult to write general text-manipulation routines when text was constantly being broken up by markers, and there could be an unbounded number of markers between each character. ------------------------------------------------------ | "a" | #<marker> | "bc" | #<syntactic-marker> | "def" | ------------------------------------------------------ The "markers embedded in lines" approach: too complex. Dan Barlow had a better idea: keep the text as a doubly linked list of strings representing lines, but still use markers to represent the beginning and end of sections with a particular syntactic type. In other words, the markers would be separated out from the text itself, making it possible to have views of the same text with different collections of markers. Primitive editing operations would then be responsible for making sure that whatever marker invariants were necessary were preserved, but this could be simpler when markers are disjoint and it's easy to pull out the set of markers affected by an operation. This is, I think, the best approach, as it would allow keeping the "line" abstraction that hemlock uses as-is. I am envisioning that markers can be used for several different purposes - extensible at the user's request. This would include: the cursor, the mark, delimiters for syntax types, even the beginning and end of the line. Allowing multiple cursor-type markers and setting one as primary would allow collaborative editing fairly easily. (On the subject of collaborative editing, the disjoint-markers idea is probably a good one here too: it means that updates to the text can be sent out without syntactic information, and each client updates the marker set to account for the new text on its own.) The next question of relevance is to figure out how to use these markers to implement knowledge of the file syntax. This Ain't Easy, for several reasons. First, we need to know the raw syntactic role of a various section of text. Is it a symbol? A string? A list opening or closing? But if we view s-expression editing via the likes of C-M-t as the same problem as syntax coloring, this means we need to maintain a nested view of the current syntax, because finding the end of the current s-expression means understanding not just the raw syntactic role of an element but its level of nesting inside other syntactic types. Nesting is also necessary for robust coloring in Common Lisp: emacs famously fails to handle nested #||# comments (and even sometimes non-nested ones), leaving most of your buffer showing in the font lock comment color. Maintaining this nested view of syntax while allowing the user to insert unbalanced syntactic elements is more than merely a SMOP, however. A simple insertion of a character might affect the syntactic type of the entire rest of the file. Inserting a closing character would revert it back then - but possibly not a clean reversion. Deleting a character might require restarting the parser at some point prior to the previous character or syntactic type change. Here are some specific examples to think about: The cursor is on #\A in "#3A((1) (2) (3))". The user hits the delete key. The cursor is on the first #\( in "() (+ 1 2))". The user hits the #\( key. The cursor is at the beginning of the second line of the following section of text. The user hits the #\" key. ------------------------------- (format nil Mary had a little lamb. Its fleece was as white as ~A. #|" '|#snow|) ; | ------------------------------- These examples demonstrate that robust syntax-aware editing is not a simple matter of local regular expressions or of a parser that can be run until the top-level syntactic role matches what it was before the edit. A single edit may actually have a deeper meaning - for instance, in the second example, inserting a paren means "insert a level of list-ness at this position in the syntactic role stack until an unmatched close paren is found on this level". To solve the problem of editing unbalanced strings or multiline comments, Andreas Fuchs suggested that it be possible to revert the syntactic type of an entire region when the insertion of an unmatched opening element would otherwise destroy this information. I think this is a good idea. It can be implemented by "hiding" one set of markers when the unmatched opening element is inserted, and un-hiding them after. Any edits the user makes in the meantime can be rectified to both the hidden and unhidden syntactic markers, thus meaning zero reparsing when the close element is inserted. However, this sounds like just the type of SMOP that is far more difficult than it sounds. I'm curious to know what other people think about this. It seems to me that this is a rather difficult problem when the various nooks and crannies of CL syntax are taken into account (unless you're willing to live with the possibility of reparsing the entire source file on many edits). If this doesn't make any sense at all I'd like to know that too. Brian -- Brian Mastenbrook "God made the natural numbers; http://www.cs.indiana.edu/~bmastenb/ all else is the work of man." bmastenb(a)cs.indiana.edu -- Leopold Kroneker

2 1

[mac-lisp-ide] re: It's quiet here
by Mikel Evins 18 Jun '04

18 Jun '04

Traffic on the mac lisp development lists tends to be light. Stuff is happening, but the Clotho and McCLIM.app hackers, at least, are fairly quiet most of the time. I try to remember to send out a status report every month or two.

1 0

[mac-lisp-ide] It's quiet here
by David Steuber 18 Jun '04

18 Jun '04

There has been no traffic. I'm just testing to make sure I'm set up on my end. -- An ideal world is left as an excercise to the reader. --- Paul Graham, On Lisp 8.1

1 0

[mac-lisp-ide] OpenMCL debug output on arbitrary stream?
by Duncan Rose 01 May '04

01 May '04

I'm not sure this is the right forum for this question; here goes anyway. I'm still slowly working on a Cocoa back end for McCLIM. The back end is now at a stage where it can run the McCLIM Listener well enough (almost!) to be used as a tool to help development. I'd like to be able to get the break loop displayed in the Listener (this would be more convenient than switching between the McCLIM Listener and the terminal / openmcl cocoa listener when errors occurred). However, I haven't got any ideas on how I'd achieve this. I know this is done in the OpenMCL Listener, but I can't see where. Can anybody provide pointers on how to do this or where to look for an existing example where it's done? -Duncan

2 1

[mac-lisp-ide] Where /is/ everyone?
by Brian Mastenbrook 23 Mar '04

23 Mar '04

Greetings all, This list has been dead for a while, so I'm wondering where everyone is? As I recall people were working on a few cool things: Clotho, McCLIM/Cocoa, and SBCL/PPC callbacks for Carbon. I'd love to know how people have been doing on these! Brian -- Brian Mastenbrook bmastenb(a)cs.indiana.edu http://cs.indiana.edu/~bmastenb/

5 7

[mac-lisp-ide] Whither CLIM/Cocoa?
by Brian Mastenbrook 01 Mar '04

01 Mar '04

Greetings fellow lispites, How is the McCLIM/Cocoa effort going? I haven't seen any news for a while and I'm dying to play with it (even if it doesn't work). Is there a CVS repository? Brian -- Brian Mastenbrook bmastenb(a)cs.indiana.edu http://cs.indiana.edu/~bmastenb/

5 9

[mac-lisp-ide] multiple-choice question
by Gary Byers 19 Feb '04

19 Feb '04

Which of the following paradigms would people most like to see in a Mac lisp IDE ? (As used below, the term "window" means what [X]Emacs would call a "frame", i.e., a window-system window, and the term "view" means about what [X]Emacs would call a "window": some portion of a window-system window used to present a buffer and associated info (modeline, etc.)). a) traditional Mac/Cocoa behavior, where there's typically a 1:1 relationship between a buffer and a window and usually a single view per window; the distinction between a buffer/view/window is often nearly (and sometimes completely) blurred. b) traditional [X]Emacs behavior, where buffers can be presented in arbitrary views in arbitrary windows. c) (a) and (b) aren't mutually exclusive: the two paradigms can be integrated in an intuitive, usable fashion (perhaps by noting that (a)'s pretty much a proper subset of (b)). This is an essay question. d) both (a) and (b) are worth supporting, but they don't mix too well: a global preference should give the user a choice between (a) and (b). e) none of the above I personally lean towards (c), but I'm still working on the essay question. I think that it's fair to say that (a)'s simpler to fit into the Cocoa document-based application model, but I think that that model's general enough to support (b) as well. Gary Byers gb(a)clozure.com

6 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mac-lisp-ide