I just put together a list of features I'd like to have in SLIME. I think it's better to post it here than letting it get dusty in my home-dir. Consider it as a base of discussion or a possible roadmap for, say, SLIME 2.0 than as a list of must-haves. It's all in the spirit of making SLIME+Lisp the superior tool to accomplish everything :) Of course, I'm willing to contribute, too.
They are ordered in terms of (by me) estimated efford.
* Nicer Homepage
How about this?: http://www.inf.tu-dresden.de/~s3815210/slime-hp-suggestion/
* Class Browser
Open a window where the class under the point is shown with all its direct superclasses and its direct subclasses or all of both.
- `s' shows/hides the class' direct slots - `m' shows/hides all methods specializing on the class
* Source Outline Mode
Provide an outline mode for lisp source. That is the user can collapse/expand single lisp expressions.
- The keybindings should be the same as in the text outline mode. - What do we show of collapsed expressions? Should a `defun' include the argument list? Should it be specific to the expression being collapsed? Should every expression be collapsible? - A block of comments may be considered a) as a single sexp b) as belonging to the next sexp (if it's on a separate line) or to the provious sexp (if it's on the same line) I favour b) since it would make a full-collapsed file more concise.
* Refactoring Aids
Provide commands for refactoring operations. Examples for useful Lisp-refactorings are: - extract/inline function/method - move slot to super-/subclass - inline temp/replace temp with query - rename function/class/slot/variable/... - ...
- We have to work out which refactorings from [1] are applicable to Lisp (and make sence) and which additional refactorings would be useful for Lisp. - Some refactorings are really hard to implement. Namely all that require a code walker - Note that refactorings are considered save modifications on _working_ code in order to ease implementation of new features. It might still be worth considering how much refactoring is possible without assuming that the code is already compiled and DTRT.
* Program Slicing
Display (only) all the code that can effect a specified object. For example if invoked on a slot name display all expressions that may change this slot's value _and_ show all expressions that effect these former statements.
- How much effort would it take to implement this? - Is it really useful for lisp? (Since lisp does indeed have side-effects, I think it would be of a certain use. So maybe the question should be: How much useful can it be for lisp?) - Can we cover all cases? - What additional information would be needed?
Footnotes: [1] "Refactoring - Improving the Design of Existing Code" by Martin Fowler et. al., Addison Wesley, 2000
Regards,
-ts
On 8815 day of my life Thomas Schilling wrote:
Source Outline Mode
Provide an outline mode for lisp source. That is the user can collapse/expand single lisp expressions.
hs-minor-mode?
Ivan Boldyrev wrote:
On 8815 day of my life Thomas Schilling wrote:
Source Outline Mode
Provide an outline mode for lisp source. That is the user can collapse/expand single lisp expressions.
hs-minor-mode?
Ah! Thanks.
I knew there must be something ;)
In my emacs implementation this has no predefined keybindings. So I'll put some in my slime-mode-hook. Hm, could be a bit more optimized but works out well, so far.
-ts
Thomas Schilling tjs_ng@yahoo.de writes:
Nicer Homepage
How about this?:
I like the design, but on my high-resolution screen most of the content is clumped together on the left side. Screenshot here: http://www.bluetail.com/~luke/misc/hp.png
I dunno nufin' about web design so no suggested fix :-)
For the rest, my personal plans for the post-1.0 SLIME future is to spend some time actually /using/ it :-)
(Well, and porting SLIME functionality to Distel.......)
-Luke
Luke Gorrie wrote:
Thomas Schilling tjs_ng@yahoo.de writes:
Nicer Homepage
How about this?:
I like the design, but on my high-resolution screen most of the content is clumped together on the left side. Screenshot here: http://www.bluetail.com/~luke/misc/hp.png
Is it better now?
I dunno nufin' about web design so no suggested fix :-)
Design is the one thing. Content and structure another. I think I have good judgement for both (all three) but I am mostly not so eager to spend too much effort in both ;-) Okay, I want to say: I'd need some help with the content, though, I'll try to reuse as much as possible. And comments are always welcome.
(And this all in case you /let/ me do it ;-)
For the rest, my personal plans for the post-1.0 SLIME future is to spend some time actually /using/ it :-)
Permitted. :-)
Okay, then consider my OP as an announcement what features I'm going to try to implement.
(Well, and porting SLIME functionality to Distel.......)
What's Distel?
Thomas Schilling tjs_ng@yahoo.de writes:
I like the design, but on my high-resolution screen most of the content is clumped together on the left side. Screenshot here: http://www.bluetail.com/~luke/misc/hp.png
Is it better now?
What about using relative sizes for the tables? At least for the non-obvious tables at the bottom this would be an improvement. Say, if you gave the table a width of 90% and every field 50% of the table width.
I dunno nufin' about web design so no suggested fix :-)
Design is the one thing. Content and structure another. I think I have good judgement for both (all three) but I am mostly not so eager to spend too much effort in both ;-)
No comment. :P
Regards,
Julian Stecklina wrote:
Thomas Schilling tjs_ng@yahoo.de writes:
I like the design, but on my high-resolution screen most of the content is clumped together on the left side. Screenshot here: http://www.bluetail.com/~luke/misc/hp.png
Is it better now?
What about using relative sizes for the tables? At least for the non-obvious tables at the bottom this would be an improvement. Say, if you gave the table a width of 90% and every field 50% of the table width.
Ah, Luke meant that part on the bottom. I thought the problem were the long lines--well, indeed I guess that's not what "clumped together" means ;-)
Well, my decision for narrowing the lines above was that it's generally considered better to have shorter lines (a rule of thumb says max. 60 characters per line). So maybe I could put a border left and right and put it all in the middle of the page. It would then still look somewhat lost on large screens but OTOH I never saw a newspaper/magazine/novel/scientific book that used a landscape paper orientation. (And: it's all for the sake of usability :)
I dunno nufin' about web design so no suggested fix :-)
Design is the one thing. Content and structure another. I think I have good judgement for both (all three) but I am mostly not so eager to spend too much effort in both ;-)
No comment. :P
Wise decision. Very wise decision... ;-)
Thomas Schilling tjs_ng@yahoo.de writes:
Well, my decision for narrowing the lines above was that it's generally considered better to have shorter lines (a rule of thumb says max. 60 characters per line). So maybe I could put a border left and right and put it all in the middle of the page. It would then still look somewhat lost on large screens but OTOH I never saw a newspaper/magazine/novel/scientific book that used a landscape paper orientation. (And: it's all for the sake of usability :)
Is HTML able to produce 2-column text? Mmmh, you could do this with tables... ;) My point is that there is enough space on the screen, so let's use it. I find web pages "optimized" for 640x480 offending...
Ok, let's discuss this in private, it's way off-topic.
Regards,
Thomas Schilling tjs_ng@yahoo.de writes:
Is it better now?
I think the page looks pretty, but it's a bit complicated.
In the current site we have all the information on one page. The new page has split the content up between 13 different pages, and it doesn't make use of most of my browser window. It looks overly split up to me: I think we have only about a page of stuff to say.
How about something good-looking that still says everything it needs to say in one easy-to-browse page?
Thomas Schilling tjs_ng@yahoo.de writes:
- Some refactorings are really hard to implement. Namely all that require a code walker
The code walker per se should be not a great problem. But it is indeed difficult to handle macros. No, I do not mean macroexpanding and walking them, but present results to the user that are "meaningful" in the sense of leaving user defined macros in their place and all.
Regards,
-
Ivan Boldyrev -
Julian Stecklina -
Luke Gorrie -
Thomas Schilling