Writing to a variable creates terser scripts but it also breaks the functional paradigm.

Currently they're part of the main body of code however it shouldn't be too difficult to turn them into optional compilable builtins

• make current variables local scoping
• local function and alias for set
• New global function will be for global vars (like how set currently is)

eg sudo vi {files}

Originally commands in murex where treated as pseudo-objects where each command could support generic returns or have a defined list of methods that could be chained. This is where the -> pipe arose from. However after implementing the POV based around that design it was becoming apparent to me that this might create an artificially steep learning curve where new users would struggle to differentiate between which commands where UNIX processes designed to pass data via anonymous pipes, and which were murex methods (particularly while the interactive shell was still missing the IDE-like context-sensitive autocomplete which I eventually have planned). Treating commands as objects also complicated things for users wanting to alias commands or create functions, as they would then need extra syntax to specify the object they're creating.

So in an effort to simplify the shell the traditional anonymous pipes, command | command, now set the IsMethod flag that was once reserved only for method pipes, ->, and all the compile time type checks for methods has been removed. This has the result of merging the behavior of | and -> while still retaining the distinction in the parser.

The reason I've wanted to retain the distinction in the parser is because I'm still not yet 100% decided on which approach I want to take. One the one hand I would like to make my shell more context aware but equally I don't want that to affect usability (like how Powershell feels awkward to use for those familiar with Bash).

My current workaround is to pass typed information as a parameter in the pipe (while not part of the pipe stream itself). This has the advantage that non-murex-based processes will work transparently but it also means that any murex commands invoked outside of the shell (eg text: example.json -> ./murex-script.mx -> murex-buildins...) cannot pass its return types back to the shell either - relying on the user to cast it manually (text: example.json -> ./murex-script.mx -> cast: json -> murex-builtins...).

Since all of the above are a pretty core implementation detail, I really need to decide which approach I'm taking. This is where I'm open to suggestions. :)

define.MimeToMurex(string) & define.GetExtType(string) now need to read from config

So users can pull a command and alter parameters from it

In the process of adding new try run modes I have broken try itself. This will need to be fixed

The code reading and writing the stream headers has been written but it hasn't yet been integrated into the stdio structs.

Current thinking, only apply to standard pipes for now. Network pipes, file system pipes etc should default to not applying the murex data type header to it. But more thought is needed here to create a clean, predictable approach with sane defaults.

• Allow more parameters in config get to drill down the config at different levels
• JSON values in config should be expanded as objects rather than strings

Currently there isn't much uniformity between the different configuration tools:

proposed:

• pipe:
  pipe --flag condition name (create pipe)
  !pipe name (close pipe)
  pipe --list (list pipes)

• event:
  event --eventtype trigger name { block } (create event)
  !event --eventtype name (close event)
  event --list (list events)

• runtime:
  runtime --option --option --option (display runtime options)

• config: (spec subject to change as currently not in line with other styles)
  config set app key value (change config)
  config get app key (get config)
  config define app key { json } (define new config options)
  !config app key (reset to default)
  config (list all config options)

So we can have prettier syntax eg:

autocomplete set command { [{
    "Dynamic": ( command -> command )
}] }

Either extend it or write some test scripts using the idiomatic Go approach.

The plan is to implement this as a builtin function. It behave something like:

a: [1..3] [a..c] b[i,o]b

which would return

["1", "2", "3", "a", "b", "c", "bib", "bob"]

(much like how globbing is treated in murex)

Replace the autocomplete set <command> function

• Comments break multiline
• h doesn't concatenate multiline
• searching through history reveals non-concatenated lines

The existing one isn't really fit for purpose. But this is a massive job.

Requirements:

• Support returns from commands that don't terminate with a CR/LF
• Support existing autocomplete framework (this shouldn't be too difficult)
• Support colourisation
• Support vim commands
• Support history (shouldn't be hard as I'm currently bypassing most of the existing readline history functionality
• Support multiline (shouldn't be hard as I'm currently bypassing most of the existing readline history functionality
• Support handling control characters (eg ^C)

To avoid race conditions with multiple murex processes changing config state

Currently it's neither documented nor discoverable.

When set, if the autocomplete list is full paths (eg root/branch/branch) then dynamically strip branches from autocomplete

This will be supported via a --stdin flag rather than enabled as a default behavior. It's an easy thing to implement but wasn't considered necessary for the MVP. However if anyone does request bumping this features priority then I will add support sooner.

It's far too strict for dealing with the wide ranging types of tabulated data from the command line.

I will write my own relaxed parser.

The idea being you only then need to know two management commands to query the state of murex:

• config: settings inside murex which can be altered
• runtime: state of murex which is either defined at compile time, or the state at runtime.

Potentially runtime can be forked from the immutable config?

I'm not sold on the names of these commands either.

The first time I loaded ./murex, I ran ls then exit
When returned to bash, no text would appear on prompt. I had to run reset
Might be an issue with pty dependency - I haven't looked into it much further than that yet.

Not sure if this is a smart idea, but it's a way of reconfiguring command line input after it's been posted. Like aliases on steroids

Hello,

I saw your comments on hacker News and found your side project here. You might be interested to know that I'm also working on a project related to improving life inside the shell. It's a terminal called Extraterm which aims to expand on the traditional idea of the terminal emulator with richer data display, better handling of text (more like a text editor at times) and also a much tighter integration with the shell. The main site is here: http://extraterm.org/ Don't forget to read the Features page and the from and show commands which allow for reuse of previous data as input to shell commands.

I see that you are experimenting with piping different data types like JSON and CSV between commands instead of just plain text/bytes. Adding direct support to Extraterm to display tabular data or tree structured data isn't outside the scope of my project.

I encourage you to brainstorm up a list of features, crazy or otherwise, that you would like to see supported on the terminal side. I can't promise anything, but I plan to make Extraterm extensible with a plugin system in the future. Having some kind of a wishlist from you would serve as great input to the design of this plugin system. I would love to see a modern shell which took advantage of a modern updated terminal.

cheers, Simon http://extraterm.org/

I don't think this issue is related to PTYs but I will need to do more research on the issue but in the meantime if anyone has any insights as to how terminal pagers work then I would welcome the feedback.

History et al work as expected but the readline package I'm using only supports prefix matching for autocompletion.

I have a nasty feeling I may need to fork the readline package or even create my own one.

Sometimes they go missing completely!!

The idea of open was that it was configurable to support any file type. Although the core functionality is already included as part of the default build, the wider side of this feature is still unfinished and the code isn't pretty. This will need doing at some point.

This has been superseded by open.

Places that will need refactoring:

• Documentation on GitHub
• Regression tests
• Go code (specifically the builtins)

Currently they're hardcoded into their respective builtins. While it makes sense to have those builtins pre-populate murex with sane defaults, there should be a way to expand, amend or even just override that list.

there was an issue while moving selection in limited complete, I updated that to paged view now

This is an experimental idea but basically a feature where you can inline Bash / Go / whatever. Some code has already been laid down for this but really it should be given a lower priority over other features. Just an interesting challenge from an engineering perspective

The history writer is just a stdio interface so add a config option to alter the history endpoint.

This is related to issue #3 though might be fixable without forking the readline package.

I'm tempted to support this via a fork builtin rather than bash's method of using an ampersand suffix (bash's method gets very annoying when dealing with query strings in URLs).

eg if the complete is file name then it should return "file name" unless the line is already inside quotes

This was broken when the event system was revised to work as a plugin system

Like grep but for ranges:

Syntax:

range --after regex --before regex

I've progressed the readline API significantly since it's first inception and added quite a few new features. However they have in turn introduced a few rendering bugs.

The plan is to rewrite the rendering functions to 1) fix those initial bugs and 2) allow the API to be expanded more in the future without the trial-and-error debugging sessions I've often needed up until now.

Currently I'm thinking no, but it would be nice to get to that stage

I either need to remove the deadlock (dangerous) or double buffer ReadAll (slow).

Will need heavy testing.

• export (stdin & no args): stdin: VARIABLE=value
• export variable (stdin & 1 arg): stdin value
• !export (stdin & no args): stdin: VARIABLE or VARIABLE=value
• !export (stdin & args): fail because mixed mode

The old code is still there and is salvagable. So hopefully it shouldn't be a massive task

Two options:

• Any command that would have failed try doesn't get added (disabled by default: enabled via config
• Any failed history variables definitely should NOT get added to history

git clone [email protected]:foo/bar.git is highly annoying. Means I have to constantly remember to escape the at character:

git clone git\@github.com:foo/bar.git

Given @ is only used for inlining arrays, it probably makes more sense for that to be separated by a white space character.

eg dd if={path}

Review what can have embedded cartridge returns:

• '\n'?
• "\n"?
• { \n }?

Also How they get concatenated (eg via line1 + \s + line2 or line1 + \n + line2