Enabling textual response and reception: hierarchy, structure and functionality


To what extent can text editing tools formalise and provide a clear understanding of the live coding practice? What can be done in order to improve textual response and reception?

Firstly, text editors of all sorts enable cyber-physical interaction. Through different key bindings, system commands and other macros, writing and accessing programmes, task fulfilment and related procedures are put at our fingertips. Highly customisable text editing environments quickly minimise time constraints and implementation efforts. In practice, user-centred textual interfaces conflate ergonomics with computational efficiency, ranging from simple task execution schemes to recursive layouts or over-the-head matrices.

A fundamental aspect of live coding is the rapid prototyping of programmes through different forms of human-computer feedback, iteration loops and scripts. With just a few keystrokes, users must be able to build programs from scratch and combine them into more complex arrangements. Text editors with embedded languages, like Emacs, provide a clear formalisation of run-time environments. In fact, this idea of extending the architecture of programming languages to fit run-time prototyping exists at the core of the live coding practice.

As I have mentioned, the idea of user-centeredness is a fundamental aspect of live coding, impossible not to notice. Thoughtless approaches often lack pragmatism and structure. However, they provide curious insights into computer literacy and human subjectivity.

Presently, textual interfaces, despite being highly configurable, lack means to deal with code anomalies creatively. Possibly, architectural deficiencies impose restrictions on user-sensitive procedures, which - to a certain extent - results in run-time design problems. In this sense, how can we develop new ways of dealing with architectural issues? What characteristics of REPL-like, scripted or fast-type environments - amongst others - can be improved in order to enable textual interactivity and facilitate the user-experience and ease of use in general?

What is the kernel of future text editing systems?

1 Like


Two thoughts about this:

  1. I believe that “user-centeredness” is not exactly the right term. Live coding gets rid of the user in favour of treating everyone as an emancipated developer. You rise an interesting question here: on a performance level, a text editor has an aesthetic and possibly political significance: we see someone write. So what is exactly the difference if someone writes like anyone else would (say, in a normal text document) or in a wizardy specialised editor?
  2. We see more and more advanced GUI systems as deep interfaces to program structure, both as representation and as intervention media. Assuming that they can be keyboard controlled instead of cursor controlled, what remains as particular significance of text?

I suggest the following answers, but I’d be curious to hear others:

  1. the gradient of abilities will include writing techniques, and emancipation will include text editing skills. Humour, error, all the everyday writing experience dimensions will continue to play a role in this.
  2. Assuming that text is an interface, then its characteristic is that its elements are nested and the nesting can be changed very fluidly by editing. The nesting is words, sentences, paragraphs, or particular equivalent code structures. The change happens through typing, but while at the same time using the nesting structure as a navigational and cognitive dimension of interaction. E.g. we jump from word to word, we select sentences, etc., and by editing, we separate and combine words, sentences, etc. All this could be done also with GUI, but it usually is not seen as a possibility.