robert-strandh / second-climacs

Version 2 of the Climacs text editor.

Second Climacs: An Emacs-like editor

Second Climacs is an Emacs-like editor written entirely in Common Lisp. It is called Second Climacs because it is a complete rewrite of the Climacs text editor.

Improvements

Climacs gave us some significant experenice with writing a text editor, and we think we can improve on a number of aspects of it. As a result, there are some major differences between Climacs and Second Climacs:

• We implemented a better buffer representation, and extracted it from the editor code into a separate library named Cluffer. The new buffer representation will have better performance, especially on large buffers, and it will make it easier to write sophisticated parsers for buffer contents.

• The incremental parser for Common Lisp syntax of Climacs is very hard to maintain, and while it is better than that of Emacs, it is still not good enough. Second Climacs uses a modified version of the Common Lisp reader in order to parse buffer contents, making it much closer to the way the contents is read by the Common Lisp compiler.

• Climacs depends on McCLIM for its graphic user interface. Second Climacs is independent of any particular library for making graphic user interfaces, allowing it to be configured with different such libraries. Though, at the moment, the only graphic user interface that exists uses McCLIM.

Quick Start

1. Make sure you have installed the dependencies:

• A recent 64-bit version of SBCL
• The system "cluffer" from the Cluffer repository
• The system "cluffer-emacs-compatibility" from the Cluffer Emacs Compatiblity
• The system "stealth-mixin", from the Stealth mixin repository
• The system "eclector", from [the Eclector3 repository]

The bash script get-dependencies.sh will do this work for you.

2. Clone the source with git:

   $ git clone https://github.com/robert-strandh/Second-Climacs
   $ cd Second-Climacs
   

3. Make sure the top-level directory can be found by ASDF.

4. Compile the editor system as follows:

   (asdf:load-system :second-climacs-clim)

5. To start Second Climacs, execute this form:

   (second-climacs-clim-base:climacs)

Documentation

Check the Documentation directory for more information.

Commands

At the moment, all you can do is type some text, and you can use C-x i to insert and existing file. Some basic Emacs commands also work, like C-f, C-b, C-p, C-n, M-<, M->, and C-x C-c. The visible window does not automatically follow the cursor yet.

Contributing

I am not accepting contributions at this time. I will make an exception for someone who is highly motivated and willing to spend time understanding the goals of the project, and then only after discussing the ideas with me.

second-climacs's Issues

Support multiple cursors properly

There should be solid support for multi-cursor operation, both at the algorithm level and the UI level.

For the Emacs UI substrate, this includes at least the following:

• Multiple regions, including the semantics of what constitutes a "region", and whether they're mandatorily tied to a point (ie. cursor) at one end, and how popping and pushing marks works with >1 point active. multiple-cursors.el has likely solved at least some of these problems already.
• Per-point ("run for all") commands, which are applied to each point/region, in a way that isolates each application and makes it appear as if only one point exists, bringing the required awareness of multi-point capabilities to a minimum. For almost all commands, this amount should be 0.
• Global ("run once") commands, which either operate in a manner independent of any points (for example M-x Switch Buffer), or do something specifically aware of multiple points
• Specific commands to manipulate the multiple points and regions themselves.

Run for all and run once commands could presumably be handled largely transparently by having appropriate mix-ins in the class hierarchy.

Write a protocol for supporting multiple major modes / syntaxes per buffer

Things like PHP, template languages, literate programming, etc. need to have multiple syntaxes and major modes per buffer. We need a protocol to formalise and support that.

It's likely that requiring explicit glue for any combination of syntaxes will be easier and more robust than trying to have it guess. Other than that, looking into how other editors (Eclipse?) do it should give us some hints as to what does and doesn't work in general.

Add a readme

Adding a simple Readme.md would be nice.

Suggestion for content
Short description.
What works and what not.
What is done, what might change, what's next.
Screencast are (almost) always nice.

Links!
To your talks about climacs, to the old climacs, etc.

folio-stream is not a stream?

When trying to type in the buffer I encountered an error

The value
  #<CLIMACS-SYNTAX-COMMON-LISP:ANALYZER {101E978973}>
is not of type
  STREAM
   [Condition of type TYPE-ERROR]

This is fixed by changing the definition of fiolio-stream to (defclass folio-stream (stream) here

Second-Climacs/Syntax/Common-Lisp/folio-stream.lisp

Line 5 in 96fd674

(defclass folio-stream ()

.

Add structured graphics and graphics-like objects with text-based fallbacks

One of the biggest problems in GNU Emacs's design is that it fundamentally pretends the display is a terminal, and treats graphical displays as a beefed-up version of text terminal, while adding support for non-character objects in a very ad-hoc, special-case manner. This means that it's neither able to take advantage of real GUI capabilities (because it still thinks in terms of character grid), nor offer any sensible fallbacks for the non-character items for actual TTY use (because they're just hacked in at particular points).

A real, designed-in support for structured graphics would let Climacs offer much better support in both worlds with minimum fuss, by being based on objects with meaningful purpose and relationships, so that alternative representations can be supplied.

One potential source of inspiration for the commands

This is just a pointer.

In the README, it says:

We are working on a way of representing commands.  We will
probably go for something similar to the CLIM macro DEFINE-COMMAND
that mentions the types of the arguments.

Maybe you could look at how stumpwm does it for some inspiration.

I was about to say that it would be very nice if the "command module" of 2nd climacs was reusable for other projects. But it looks like you already took care of that (i.e. it has its own system).

Add per-buffer content-attached data shared between views

It's useful to have the ability anchor pieces of data to the buffer contents, in a way that's shared and visible to all the views into the buffer. One obvious use-case is syntax parse info, but there are more uses for it, and the mechanism shouldn't be tied specifically to the syntax, as it's also useful for syntaxless buffers and transient data.

One scenario in which this comes handy is marking search occurrences across multiple views, when these views are substantially different. For example, when editing a TeX document, the user could mark a section in the source, then be shown the same place in the rendered preview and possibly lint buffer if there's any pertinent output.

By having the information about "marked place" be tied to the buffer and shared by views, we make it possible to ensure that all views are in fact showing the exact same thing, greatly simplifying verification of the output. The same principle applies to any scenario where "the contents" of the buffer have more than one possible rendering, such as SVG editing, declarative syntax in UI builders (XUL/XAML/Android XML UI), etc. Likewise, more than just current occurrence could be of use between multiple views, and there should be a standard dictionary of the types of such data pieces.

`get-dependencies.sh` error: `fatal: repository '#' does not exist`

Bash does not consider # as the beginning of a comment if it is embedded in a string:

DEPENDENCIES="
https://github.com/robert-strandh/Acclimation
https://github.com/robert-strandh/Clump
https://github.com/robert-strandh/cluffer
https://github.com/robert-strandh/cluffer-emacs-compatibility
https://github.com/robert-strandh/SICL
https://github.com/robert-strandh/Stealth-mixin
https://github.com/s-expressionists/Eclector
#
# Uncomment the following two dependencies to build the Climatis
# (non-McClim) version of Second-CLimacs.
#
# https://github.com/robert-strandh/Climatis
# https://github.com/Shinmera/trivial-benchmark
"

Hence, $DEPENDENCIES contains # that is considered later as a repository that the script tries to download. Since it is not a valid repository, the following error appears during the run:

fatal: repository '#' does not exist

A possible solution would be to append the two extra dependencies as follows:

#
# Add dependencies URLs here
#
DEPENDENCIES="
https://github.com/robert-strandh/Acclimation
https://github.com/robert-strandh/Clump
https://github.com/robert-strandh/cluffer
https://github.com/robert-strandh/cluffer-emacs-compatibility
https://github.com/robert-strandh/SICL
https://github.com/robert-strandh/Stealth-mixin
https://github.com/s-expressionists/Eclector
"
#
# Uncomment the following two dependencies to build the Climatis
# (non-McClim) version of Second-CLimacs.
#
DEPENDENCIES="
${DEPENDENCIES}
https://github.com/robert-strandh/Climatis
https://github.com/Shinmera/trivial-benchmark
"

Eclector not installed after running get-dependencies.sh