{"id":25195877,"url":"https://github.com/s-expressionists/editing-requirements","last_synced_at":"2026-02-25T05:33:26.420Z","repository":{"id":115334408,"uuid":"352969339","full_name":"s-expressionists/editing-requirements","owner":"s-expressionists","description":"Collecting requirements for editing, parsing, analyzing and presenting Common Lisp code","archived":false,"fork":false,"pushed_at":"2021-04-04T19:28:19.000Z","size":11,"stargazers_count":5,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"main","last_synced_at":"2025-10-26T01:35:38.399Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/s-expressionists.png","metadata":{"files":{"readme":"README.org","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-03-30T11:01:01.000Z","updated_at":"2024-07-17T14:26:09.000Z","dependencies_parsed_at":null,"dependency_job_id":"aabf587a-0ebf-463a-88b3-a90e53b840ec","html_url":"https://github.com/s-expressionists/editing-requirements","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/s-expressionists/editing-requirements","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s-expressionists%2Fediting-requirements","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s-expressionists%2Fediting-requirements/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s-expressionists%2Fediting-requirements/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s-expressionists%2Fediting-requirements/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/s-expressionists","download_url":"https://codeload.github.com/s-expressionists/editing-requirements/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/s-expressionists%2Fediting-requirements/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29811559,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-25T03:30:18.102Z","status":"ssl_error","status_checked_at":"2026-02-25T03:30:17.799Z","response_time":61,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-02-10T01:38:58.693Z","updated_at":"2026-02-25T05:33:26.404Z","avatar_url":"https://github.com/s-expressionists.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"#+TITLE: Requirement Analysis for a Common Lisp Editing and Parsing Framework\n\n#+OPTIONS: toc:1\n\n#+STARTUP: outline\n#+HTML_HEAD_EXTRA: \u003cstyle\u003ebody { width: 60%; margin-left: 20% } body { margin:40px auto; line-height:1.6; font-size:18px; color:#444; padding:0 10px } h1,h2,h3 { line-height:1.2 } .sidenote { display: block; float: right; width: 30%; border: 2px solid #888; margin: 20px; padding: 3px; }\u003c/style\u003e\n\n#+MACRO: cl Common Lisp\n#+MACRO: lisp src_lisp[:exports code]{$1}\n\n* Introduction\n\n  The purpose of this document is to write down already discussed as\n  well as additional requirements and design considerations for\n  software modules that edit, parse, analyze and present {{{cl}}}\n  code.\n\n** Scope\n\n   Out of scope:\n   + Command processing\n   + Syntax highlighting themes\n   + Completion\n   + Indentation\n   + New input editor for McCLIM\n   + Full-blown IDE\n\n* Usage Scenarios\n\n** Source Code Editor for a Future Common Lisp IDE\n\n   This scenario is concerned with a graphical (as in not limited by\n   capabilities of text-based terminals) editor/IDE for text-based\n   editing (as in not a structure editor) of Common Lisp source code.\n\n*** Source Code Display\n\n    1. As a user of the IDE, I want the source code to be highlighted\n       according to syntactic and semantic properties (examples:\n       symbol and package status, commented/skipped, evaluated\n       vs. unevaluated vs. quasiquote level, namespace, defined\n       vs. undefined) in order to grasp the aspects relevant to me\n       more quickly.\n\n    2. As a user of the IDE, I want to see the relation between the\n       source code and the/a live image in order to not accidentally\n       run old code. (Example: Renaming a function in the source code\n       leads to two differences: 1) a function in the live image is no\n       longer backed by code 2) a function in the source code is not\n       present in the image)\n\n    3. As a user of the IDE, I want to affect the live image by\n       performing commands directly on objects in the source code\n       (examples: (un)evaluate definition, (un)comment definition,\n       (un)trace function) so that I don't have to type names of\n       things.\n\n    4. As a user of the IDE, I want to browse and query the *lexical*\n       structure of the code within files (example structure:\n       in-packages » toplevel definitions » contained slots, local\n       functions) in order get a quick overview and navigate quickly.\n\n    5. As a user of the IDE, I want to browse and query the *logical*\n       structure of the code across files (example structure:\n       in-packages » generic function » methods) in order get a quick\n       overview and navigate quickly.\n\n    6. As a user of the IDE, I want to be able to configure the fonts\n       (*including variable-width fonts*) and colors used to display\n       source code in order to meet my aesthetic and ergonomic needs.\n\n    7. As a user of the IDE, I would like to hover the pointer over,\n       or move the cursor to, a variable or a function name, and have\n       all occurrences of the same object (considering lexical and so\n       on) be highlighted (perhaps using a different style of\n       highlighting, like changing the background color) so I can\n       immediately estimate the impact of changes and maybe also\n       initiate certain changes.\n\n    8. As a user of a code editor, most of my work is done on regions\n       of code that don't work (yet), so I want as much of the\n       functionality as possible to operate on such invalid code.\n\n       Example: Changing a {{{lisp(let)}}} to a {{{lisp(let*)}}} when\n       I've just opened the parens for the second binding).\n\n    9. As a user of the IDE, I would like to be able, to 'pretend' I\n       am working in one environment even while working in another in\n       order to quickly explore or validate my code without actually\n       switching environment.\n\n       Example: I would like to be able to see what {{{lisp(#+(and ccl\n       macos 128bit))}}} looks like even if I'm really on\n       {{{lisp(#+(and sbcl win32 64bit))}}}.\n\n       The IDE should automatically accumulate a list of all\n       combinations of features for which different regions of the\n       source code will be active.\n\n*** Editing\n\n    1. As a user of the IDE, I want to be able to edit with multiple\n       cursors, so I can perform similar operations at multiple\n       locations at once and thus save typing.\n\n    2. As a user of the IDE, I would like to perform editing\n       operations on objects in the source code that consider their\n       semantics in order to preserve the validity of the code more\n       easily (Like perhaps a cursor positioned to each occurrence.\n       Or perhaps saving three positions in a secret place that I can\n       later jump to. Or something like that.)\n\n*** Errors\n\n    1. As a user of the IDE, I want to be immediately notified of\n       syntactic and statically detectable problems with the code I\n       entered.\n\n    2. As a user of the IDE, I want errors, warnings and notes\n       pertaining to the source to be indicated in the [[term-fringe][fringe area]] in\n       order to quickly spot problematic lines.\n\n    3. As a user of the IDE, I want errors that concern multiple\n       locations (examples: redefinition of a function or method\n       within a single file, invalid declarations and the thing they\n       pertain to) to be indicated in a suitable manner so I don't\n       have to manually resolve line numbers or other location\n       encodings.\n\n*** Linting\n\n    1. As a user of the IDE, I want the package definitions in my\n       project to be checked for problems so that I can keep the\n       package definitions clean. Examples:\n\n       + When a package is {{{lisp(:use)}}}d, at least one symbol\n         should be mentioned.\n\n       + When {{{lisp(:import-from)}}} is used, the imported symbols\n         should be mentioned.\n\n       + Symbols which are {{{lisp(:export)}}}ed should name something\n         in at least one namespace or have a comment explaining why\n         they are exported.\n\n       + An exported symbol should not be spelled with two package\n         markers.\n\n       + A symbol exported from a {{{lisp(:use)}}}d package should not\n         be spelled with any package markers.\n\n    2. As a user of the IDE, I want to be notified if my code violates\n       formatting conventions so I don't have to make a separate\n       effort to clean up my code. Examples:\n\n       + ~) )~.\n\n       + Closing parenthesis on a separate line.\n\n       + Incorrect number of semicolons in a line comment.\n\n    3. As a user of the IDE, I want to be notified if my code contains\n       read-time conditionals that are either unsatisfiable or\n       redundant so that I can correct the issue with loading the code\n       in that environment.\n\n*** Non-functional requirements:\n\n    1. Flicker-free updates\n\n    2. Parsing, analysis and feedback at typing speed\n\n    3. Must work on any source code regardless of whether the code is\n       represented (\"loaded\") in the live image.\n\n** Basis for an Improved Terminal REPL\n\n   A proper implementation of this https://techfak.de/~jmoringe/linedit-1.ogv.\n\n   1. As a user of an improved REPL, want the input and the output to\n      appear in separate \"buffers\", and I often want to be able to\n      restrict things like search commands to the output of one\n      particular input, typically the latest.\n\n** Basis for a Common Lisp Language Server\n\n   An implementation of the [[https://microsoft.github.io/language-server-protocol/][Language Server Protocol]] for Common Lisp\n   allows editors and IDEs to support some aspect of Common Lisp\n   development. There are already such implementations but they seem\n   to be based on 1) regular expressions for syntax 2) SWANK for\n   semantics. The former limits the precision and depth of analysis,\n   the latter limits some features to code that is/can be loaded into\n   the live image.\n\n** Source Code Highlighting for a Documentation Formatting System\n\n   For highlighting and cross-referencing source code snippets within\n   technical documentation.\n\n   Essentially a better version of the syntax highlighting and links\n   in this\n   https://techfak.de/~jmoringe/presentation-eclector/slides.html#/slide-slide%3Aerrors%3Arecovery-example-2\n\n** Basis for Batch Static Analysis Tools\n\n   running \"deeper\" and more global static analyses on larger bodies\n   of code as a batch process (e.g. looking at all methods of a\n   generic function within a whole code base to validate adherence to\n   a defined protocol)\n\n* Requirements\n\n  This section is intended to extract and condense requirements from\n  the different [[*Usage Scenarios][scenarios]] into a single list:\n\n  + Functional\n    + Support multiple syntaxes\n    + Support display with variable width fonts\n    + Support link to AST or semantic level\n    + Support comments and other normally skipped input\n    + Highlighting should be able to depend on context: quoted\n      material that is the first argument of {{{lisp(make-instance)}}}\n      is a class name.\n  + Non-functional\n    + Flicker-free redisplay\n    + Process and redisplay at higher speed than typing speed\n    + Display code should be independent of syntax if possible\n    + Must handle large amounts of source code (maybe around 1 MLoC?)\n      in memory.\n\n* Design\n\n** Modules and Responsibilities\n\n   + Buffer ::\n   + Analyzer ::\n   + View ::\n   + Concrete Syntax Representation ::\n   + Abstract Syntax Representation ::\n   + Character Syntax Parser ::\n   + S-expression Syntax Parser ::\n   + File syntax Parser ::\n\n* Unsorted\n\n** Result Representation\n\n   1. Single result tree (somehow combining e.g. CST and AST)\n\n      + Could be good for structure-based editing and movement\n        (\"forward-expression\", \"move up\", paredit operations)\n\n      + Likely hard to construct in a technically and theoretically\n        sound way (e.g. How would AST nodes store CST children?)\n\n   2. Multiple result trees for e.g. CST and AST with \"origin\" or\n      \"source\" links between the phases\n\n      + Relatively straightforward to construct\n\n** Two Strategies\n\n   1. Traverse syntax tree outputting chunks of text\n\n   2. Iterate through text characters and track current path in syntax\n      tree\n\n* References and Related Work\n\n  + Climacs and DREI\n  + Second Climacs\n  + Emacs, LEM, etc.\n\n* Discussions\n#+BEGIN_EXAMPLE\n  \u003cscymtym\u003e beach: regarding future work, i'm not sure. i will probably try to hook up the s-expression-level parsing as a tech demo and as a debug tool for the parsing machinery. i guess the central question is whether i'm making a throw-away adapter without touching DREI much or whether i will try to improve DREI. i don't think i understand DREI well enough to make such a decision yet\n  \u003cscymtym\u003e considering things from the requirements perspective, i often wished i had a CLIM-based code editor with syntax (or semantics) highlighting and annotations under my control. DREI would be the obvious solution, but it may not be the best one. i guess there are also jackdaniel's plans for a new editor and your architecture for second climacs to consider\n  \u003cscymtym\u003e even more broadly, i may also try to package the parsing and static analysis stuff as a language server again since that seems to be a thing people want\n  \u003cbeach\u003e scymtym: Thanks for the overview.  I know what solution I would personally prefer, of course.\n  \u003cscymtym\u003e beach: which one would that be?\n  \u003cbeach\u003e Well, I think DREI is doomed as an input editor, given jackdaniel's plans, and, like I said, I am not sure all those features are needed in an input editor, so that would be fine with me.\n  \u003cbeach\u003e But we still need a full Common Lisp editor in Common Lisp and CLIM/McCLIM.\n  \u003cbeach\u003e I am not particularly attached to the code base of Second Climacs, but I do think the buffer management and the Common Lisp parsing mechanism is the right one.\n  \u003cbeach\u003e So, we could start from scratch if you like, just keeping the buffer and the parser.\n  \u003cbeach\u003e The crucial missing link I think is indentation.\n  \u003cbeach\u003e I have had some ideas about that, but haven't had time to act upon them.\n  \u003cbeach\u003e But I have been a little confused by your experiments...\n  \u003cbeach\u003e I can't tell whether they are throw-away experiments, or whether you are working on something more permanent.\n  \u003cbeach\u003e But it seems you haven't decided that yet.\n  \u003cscymtym\u003e right, i don't know yet either in some cases. i'm pretty certain that i want eclector and the s-expression parser as the base. i also have a \"file syntax\" system that is responsible for reading multiple toplevel forms and managing environments. i think something like that will be needed and it is probably good to keep it separate from an editor's parsing logic (unlike the module structure used by DREI)\n  \u003cscymtym\u003e everything above that level are throw-away experiments so far. i will probably keep working on the SBCL IR and BIR visualizers if people find them useful but they don't impose many requirements on the design and generally touch input editing only tangentially\n  \u003cbeach\u003e I am more \"worried\" about the low-level parts of your experiments.  It seems to me that Cluffer and the incremental parser of Second Climacs would be an ideal basis for all the rest.\n  \u003cbeach\u003e But you never mention those, so I am not sure whether you have decided you don't want those.\n  \u003cbeach\u003e Well, not the basis for everything, of course.\n  \u003cbeach\u003e Sometimes, you don't need to parse program text at all, like if it is already available as s-experssions.\n  \u003cbeach\u003e expressions\n  \u003cscymtym\u003e those are multiple aspects. can you describe the use-case in which the s-experssions are already available?\n  \u003cbeach\u003e No. :)\n  \u003cbeach\u003e I don't know of such a scenario right now.  But I can imagine one.\n  \u003cscymtym\u003e ok, but the other point is important as well\n  \u003cbeach\u003e What other point?\n  \u003cscymtym\u003e using cluffer/second climacs instead of DREI's buffer and incremental parsing\n  \u003cbeach\u003e Ah, yes.  DREI's technique is dead.\n  \u003cbeach\u003e So it seems to me that we (you and me at least) should agree on a common base for future work.\n  \u003cbeach\u003e And, again, since you haven't told me your opinion on the Second Climacs technique, I don't know what to think.\n  \u003cscymtym\u003e is the probably with DREI the architecture or the parsing technique(s)?\n  \u003cscymtym\u003e *is the problem\n  \u003cbeach\u003e Both.\n  \u003cbeach\u003e The buffer representation is not good, and it uses a parsing technique that doesn't scale, and that is as broken as regular expressions.\n  \u003cscymtym\u003e i had the expression that the parsing technique can by chosen by the syntax implementation, that's why i ask\n  \u003cbeach\u003e Indeed it can.  So I guess it would be technically possible to plug in the parsing technique of Second Climacs.\n  \u003cbeach\u003e But then what is left?\n  \u003cscymtym\u003e and the buffer representation seems to allow for different implementations as well\n  \u003cbeach\u003e Only the buffer representation.  And it is broken too.\n  \u003cbeach\u003e OK, then you tell me what is left if we replace both those.\n  \u003cscymtym\u003e i think the redisplay engine and command processing are other more or less separate parts\n  \u003cscymtym\u003e but there may be better ways do implement those, of course\n  \u003cbeach\u003e Fine, command processing can be re-used.  I don't think it is broken.\n  \u003cbeach\u003e But redisplay is probably also broken.\n  \u003cscymtym\u003e in fact, the presence of ESA in DREI i something that i deeply dislike\n  \u003cbeach\u003e Cluffer was designed to allow multiple windows into the same buffer, and I don't think DREI can handle that very well.\n  \u003cbeach\u003e So I think we just killed the last component of DREI, no?\n  \u003cscymtym\u003e there can be multiple VIEWs, each with its own SYNTAX, i think\n  \u003cscymtym\u003e note that i'm not trying to defend DREI\n  \u003cbeach\u003e Perhaps, but it is not incrementally updated as Cluffer allows.\n  \u003cscymtym\u003e i want to understand what the flaws are before we start from scratch\n  \u003cbeach\u003e Sure.\n  \u003cscymtym\u003e i mean the fundamental flaws, as a code base, DREI is pretty bad, but that could in theory be fixed\n  \u003cbeach\u003e So here is what I think...\n  \u003cbeach\u003e I think we (and by \"we\", I mainly mean \"I\") have learned a lot since (first) Climacs and DREI were written.  I also think that most of it is broken.  Finally I think starting from scratch is not a big deal.  And editor like that is not very complicated, aside from the stuff that must be replaced anyway.\n  \u003cscymtym\u003e would processing without displaying anything be in scope for cluffer/second climacs? this comes up when implementing a language server since the editor does all the display and only send buffer contents and modification commands to the language server\n  \u003cbeach\u003e Definitely.\n  \u003cbeach\u003e Cluffer is designed so that observers decide when to redisplay.\n  \u003cbeach\u003e And what they then do is to incrementally update their view of the buffer contents.\n  \u003cbeach\u003e So there is no observer visible to Cluffer.\n  \u003cscymtym\u003e and the \"view\" could also be, for example, an AST and list of errors to send to some editor instead of something displayed to the user in some fashion?\n  \u003cbeach\u003e I think ESA was an interesting idea, but it wasn't done right.\n  \u003cbeach\u003e I think that would be entirely possible.\n  \u003cscymtym\u003e where would cursors, motion, text manipulation commands, etc. go in this architecture? a separate layer on top?\n  \u003cbeach\u003e Yes.  The Cluffer design allows for higher level editing commands to be implemented as repeated invocation of lower-level commands in an efficient way, so it proposes only the basic stuff.\n  \u003cbeach\u003e Cluffer allows for clients to create cursors and it moves them appropriately when text is altered.\n  \u003cscymtym\u003e i see. so i think a minimal useful module would provide a buffer with fundamental modification operations and cursors as well as a view that associates an incrementally maintained analysis result with the buffer\n  \u003cscymtym\u003e does that make sense?\n  \u003cbeach\u003e Yes, and that is the current state of Second Climacs.  Plus a bit more for the incremental Common Lisp parser, of course.\n  \u003cscymtym\u003e things to implement on top of this would be: complex editing commands for users, graphical display, language server and probably other thins as well\n  \u003cscymtym\u003e *things\n  \u003cbeach\u003e Sure.  \"graphical display\"?\n  \u003cscymtym\u003e i assume this basic module wouldn't know anything about CLIM, terminals or other forms of displaying the buffer content\n  \u003cbeach\u003e Yes, I see.  Sure.  Thought I did implement a primitive display module too.  Based on explicit manipulation of output records, so designed to be fast for large displays.\n  \u003cbeach\u003e That one could be ripped out.  I am not particular proud of it.  But I think manipulating output records explicitly is the right approach.\n  \u003cscymtym\u003e my initial hunch is to provide all forms of textual or graphical presentation as separate modules\n  \u003cbeach\u003e Sounds right.\n  \u003cscymtym\u003e ok, i will study the second climacs code base (again)\n  \u003cbeach\u003e So the incremental parser is an intermediate between the buffer and the display.\n  \u003cbeach\u003e It is part of the observer.\n  \u003cbeach\u003e It structures the contents of the buffer into nested \"parse results\".\n  \u003cscymtym\u003e that's similar to what i do. with DREI, i then have to look through the parse result tree and find the correct node for a given input position\n  \u003cbeach\u003e I see.\n  \u003cscymtym\u003e it would be nice to do that in a less roundabout way\n  \u003cbeach\u003e I agree.\n  \u003cbeach\u003e I am not sure I found a good solution to that problem.\n  \u003cbeach\u003e If you have any question about Second Climacs, don't hesitate.  And remember that I am not proud of the organization of the code.  Only of those two things: the buffer and the incremental parser.\n  \u003cscymtym\u003e ok\n  \u003cscymtym\u003e one more thing, though: do you think something like parsing code snippets for syntax highlighting and cross-referencing in a documentation formatting system would also be in scope? since there would no need for modification or incremental parsing\n  \u003cbeach\u003e If the \"documentation formatting system\" works as a batch processor, there wouldn't be much use for either the buffer or the incremental parser.\n  \u003cbeach\u003e But if it is interactive, then yes.\n  \u003cbeach\u003e I mean, the incremental parser is just Eclector, but with a short circuit for parse results that have not been modified, so if things are not modified, then it boils down to just Eclector.\n  \u003cscymtym\u003e true, but i would like to base as much as possible on a common foundation. for example, the functionality for syntax highlighting should work in an editor and also the documentation formatting system\n  \u003cscymtym\u003e concretely, the difference could be designing interfaces with buffers or with streams as the input representation\n  \u003cbeach\u003e Sure, but both those usages would work on an s-expression (or CST) version of the input, so they would be at a higher level, no?\n  \u003cbeach\u003e Well, not CST.  parse result.\n  \u003cbeach\u003e To include comments and such.\n  \u003cscymtym\u003e the classification part of the syntax highlighting would work on even higher level with some AST-ish elements, i think. but mapping nodes and chosen highlighting styles back to input positions or ranges would somewhat depend on the input representation\n  \u003cbeach\u003e Yes, I see.\n  \u003cbeach\u003e By the way, in Common Lisp, once the observer has been updated, it becomes a stream that it feeds to Eclector.\n  \u003cbeach\u003e Sorry in Second Climacs I mean.\n  \u003cbeach\u003e ACTION chose the wrong abbrev. *blush*\n  \u003cscymtym\u003e heh\n  \u003cbeach\u003e \"cls\" is Common Lisp  and \"scl\" is Second Climacs.\n  \u003cscymtym\u003e ok, i can see two immediate next steps for me: 1) write down the different use-cases and requirements 2) study the second climacs code base\n  \u003cscymtym\u003e maybe i can continue to think about modules and interfaces and present a proposal after that\n  \u003cbeach\u003e Sure.  I absolutely do not want to force you to use Second Climacs, but I do think its base is much more sane than that of DREI, and I am also convinced that we should find a common base.\n  \u003cbeach\u003e That sounds good.\n  \u003cscymtym\u003e i currently expect to use the buffer and incremental parsing part of second climacs as the base for one module\n  \u003cbeach\u003e Again, sounds good.\n  \u003cscymtym\u003e and i would leave out the question of replacing McCLIM's input editor for this consideration\n  \u003cbeach\u003e I agree.\n  \u003cscymtym\u003e great, thanks for your input\n  \u003cbeach\u003e Pleasure.\n  \u003cbeach\u003e For indentation, my latest thinking is to use standard objects to represent various forms.  Like a LET would be represented by a standard object containing an instance of a BINDINGS class, and an instance of an ORDINARY-BODY class.  Generic functions would take such instances as arguments and compute the desired indentation.\n  \u003cbeach\u003e Er, I didn't mean for representing the forms themselves.\n  \u003cbeach\u003e I mean for representing indentation information of different forms, determined by the operator.\n  \u003cscymtym\u003e i have second climacs somewhat working with eclector. error handling and recovery can now be improved, i think\n  \u003cbeach\u003e Still, that's great!\n  \u003cbeach\u003e As I recall, I tried to handle all Eclector errors, but I think Eclector can do that better by recovering.\n  \u003cbeach\u003e I mean, I think I started on a path of including handlers for all Eclector errors.\n  \u003cbeach\u003e So you are using the incremental parser for Common Lisp code?\n  \u003cscymtym\u003e yes, i'm replacing the sicl reader with eclector in the second climacs code base\n  \u003cbeach\u003e Excellent!\n  \u003cscymtym\u003e (that's one way to study the code base)\n  \u003cbeach\u003e I noticed I have a few changes that I never committed.  One is to update the Clouseau entry point name from INSPECTOR to INSPECT.\n  \u003cbeach\u003e But I guess you already fixed that one, yes?\n  \u003cscymtym\u003e there seems to be a merged pull request for that in the commit log. maybe you accepted that pull request in the GitHub web interface and did not update your local repository?\n  \u003cscymtym\u003e but yeah, that's the least of my concerns\n  \u003cbeach\u003e Oh, let me pull.\n  \u003cbeach\u003e Sure enough.  Also, can I delete the Eclector-test directory now?  And the SICL reader?\n  \u003cscymtym\u003e i think it makes more sense that i submit a pull request that switches to eclector and removes the obsolete parts. there will be conflicts if you do some of that at the same time\n#+END_EXAMPLE\n\n#+BEGIN_EXAMPLE\n  \u003cscymtym\u003e beach: you asked whether the redisplay technique in second climacs\n            would be sufficient once McCLIM gets double buffering. i don't know\n            yet, but i can see several aspects. 1) the current technique seems\n            to assume fixed-width fonts 2) currently, a lot of work is done\n            per-wad and all visible wad are repainted . this could be avoided by\n            caching but that would eventually lead to a DREI-style redisplay (i\n            don't know whether that's good or\n  \u003cscymtym\u003e bad) 3) most methods i have seen (or implemented myself) work with a\n            current path through the parse result tree, that is with some\n            context, to determine highlighting style and other properties (CSS\n            is like that as well) while second climacs currently directly\n            associates styles with wads (mostly)\n#+END_EXAMPLE\n* Terminology\n\n  + \u003c\u003cterm-fringe\u003e\u003e fringe :: An area left or right of the text that\n       can contain additional information pertaining to visible lines\n       of text. Typical examples of such information are line numbers,\n       version control status, indicators for errors, warnings and\n       notes.\n\n  + \u003c\u003cterm-fringe-indicator\u003e\u003e fringe indicator :: A textual or\n       graphical element in the [[term-fringe][fringe]] area.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fs-expressionists%2Fediting-requirements","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fs-expressionists%2Fediting-requirements","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fs-expressionists%2Fediting-requirements/lists"}