roc-lang/roc
1
1
Fork 0
mirror of https://github.com/roc-lang/roc.git synced 2024-11-11 05:34:11 +03:00
Code Issues Packages Projects Releases Wiki Activity
80736f93b9
roc/editor/editor-ideas.md
Anton-4 60e0f4d4db
more ideas
2021-02-13 19:09:40 +01:00

13 KiB
Raw Blame History

(For background, this talk has an overview of the design goals for the editor.)

Editor Ideas

Here are some ideas and interesting resources for the editor. Feel free to make a PR to add more!

Sources of Potential Inspiration

These are potentially inspirational resources for the editor's design.

Nice collection of research on innovative editors, link.

Package-specific editor integrations

(Or possibly module-specific integrations, type-specific integrations, etc.)

Live Interactivity

Debugging

Structured Editing

Productivity features

  • When refactoring;
    • Cutting and pasting code to a new file should automatically add imports to the new file and delete them from the old file.
    • Ability to link e.g. variable name in comments to actual variable name. Comment is automatically updated when variable name is changed.
  • Automatically create all "arms" when pattern matching after entering when var is based on the type.
    • All when ... is should be updated if the type is changed, e.g. adding Indigo to the Color type should add an arm everywhere where when color is is used.
  • When a function is called like foo(false), the name of the boolean argument should be shown automatically; foo(is_active:false). This should be done for booleans and numbers.
  • Suggest automatically creating a function if the compiler says it does not exist.
  • Integrated search:
    • Searchbar for examples/docs. With permission search strings could be shared with the platform/package authors so they know exactly what their users are struggling with.
  • Show productivity/feature tips on startup. Show link to page with all tips. Allow not seeing tips next time.
  • Search friendly editor docs inside the editor. Offer to send search string to Roc maintainers when no results, or if no results were clicked.

Autocomplete

  • Use more space for autocomplete options:
    • Multiple columns. Columns could have different sources, i.e. middle column suggests based on current folder, left column on whole project, right column on github.
    • show cell with completion + auto import suggestion
  • Webcam based eye tracking for quick selection.
  • Machine Learning:
    • GPT-3 can generate correct python functions based on a comment describing the functionality, video here. It's possible that training a model using ast's may lead to better results than text based models.

Productivity Inspiration

  • Kite AI autocomplete and doc viewer.

Non-Code Related Inspiration

  • Scrivner writing app for novelists, screenwriters, and more
  • Word processors (Word, Google Docs, etc)
    • Comments that are parallel to the text of the document.
    • Comments can act as discussions and not just statements.
    • Easy tooling around adding tables and other stylised text
  • Excel and Google Sheets
    • Not sure, maybe something they do well that we (code editors) could learn from

Machine Learning Ideas

  • Ability to record all changes to abstract syntax tree with user permission.
    • I think it is possible to create powerful automatic error resolution by having a dataset available of ast's with a specific error and the subsequent transformation that fixed the error.
    • Users with large private code bases could (re)train a publicly available error recovery model to experience benefits without having to share their code.
    • It could be useful to a user who is creating a function to show them the most similar function (type signature, name, comment) in a public+their private database. Say I was using a web framework and I just created a function that has a multipart form as argument, it would be great to have an example instantly available.
      • A simpler start for this idea without user data gathering: how the user a code snippet that is most similar to what they are currently writing. Snippets can be aggregated from examples, tests, docstrings at zero cost to the package/platform authors.
  • Fuzzy natural language based setting adjustment in search bar or with voice input: increase font size, enable autosave, switch to light theme...
  • Voice input:
    • Good for accessibility.
    • https://www.youtube.com/watch?v=Ffa3cXM7bjc is interesting for inspiration.
    • Could be efficient way to communicate with smart assistant.
    • Describe actions to execute them, examples:
      • Add latest datetime package to dependencies.
      • Generate unit test for this function.
      • Show edit history for this function.
    • Mozilla DeepSpeech model runs fast, works pretty well for actions but would need additional training for code input. Possible to reuse Mozilla common voice for creating more "spoken code" data.

Testing

  • From Google Docs' comments, adding tests in a similar manner, where they exists in the same "document" but parallel to the code being written
    • Makes sense for unit tests, keeps the test close to the source
    • Doesn't necessarily make sense for integration or e2e testing
    • Maybe easier to manually trigger a test related to exactly what code you're writing
  • Ability to generate unit tests for a selected function in context menu
    • A table should appear to enter input and expected output pairs quickly
  • Ability to "record" unit tests
    • Select a function to record.
    • Do a normal run, and save the input and output of the selected function.
    • Generate a unit test with that input-output pair

Documentation

  • Ability to see module as it would be presented on a package website.
    • Modern editors may guide developers to the source code too easily. The API and documentation are meant to interface with humans.

General Thoughts/Ideas

Thoughts and ideas possibly taken from above inspirations or separate.

  • ACCESSIBILITY === EMPATHY

    • Visual Imapirments No Animation is most benign form of cognitive disabity but really important base line of people with tense nerve system. Insensitivity to certain or all colors. Need of highcontrast Or Everything Magnified for me with no glasses. Or Total blindness where we need to trough sound to communicate to the user Screen readers read trees of labeled elements. Each platform has different apis, but I think they are horrible. Just close your eyes and imagine listening to screen reader all day while you are using this majectic machines called computers. But blind people walk with a tool and they can react much better to sound/space relations than full on visal majority does. They are acute to sound as a spatial hint. And a hand for most of them is a very sensitive tool that can make sounds in space. Imagine if everytime for the user doesnt want to rely on shining rendered pixels on the screen for a feedback from machine, we make a accoustic room simulation, where with moving the "stick", either with mouse or with key arrows, we bump into one of the objects and that produces certain contextually appropriate sound (clean)ding

      On the each level of abstraction they can make sounds more deeper, so then when you type letters you feel like you are playing with the sand (soft)shh. We would need help from some sound engeneer about it, but imagine moving down, which can be voice trigered command for motion impaired, you hear (soft)pup and the name of the module, and then you have options and commands appropriate for the module, they could map to those basic 4 buttons that we trained user on, and he would shortcut all the soft talk with click of a button. Think of the satisfaction when you can skip the dialog of the game and get straight into action. (X) Open functions! each function would make a sound and say its name, unless you press search and start searching for a specific function inside module, if you want one you select or move to next.

    • Motor impariments [rant]BACKS OF CODERS ARE NOT HEALTHY! We need to change that![/neverstop] Too much mouse waving and sitting for too long is bad for humans. Keyboard is basic accessability tool but Keyboard is also optional, some people have too shaky hands even for keyboard. They rely on eye tracking to move mouse cursor arond. If we employ some voice recognition functions we could make same interface as we could do for consoles where 4+2 buttons and directional pad would suffice. That is 10 phrases that need to be pulled trough as many possible translations so people don't have to pretend that they are from Maine or Texas so they get voice recognition to work. Believe me I was there with Apple's Siri :D That is why we have 10 phrases for movement and management and most basic syntax.

  • Nice backtraces that highlight important information

  • Ability to show import connection within project visually

    • This could be done by drawing connections between files or functions in the tree view. This would make it easier for people to get their bearings in new big projects.

  • Connections could also be drawn between functions that call each other in the tree view. The connections could be animated to show the execution flow of the program.

  • Ability to inline statements contained in called functions into the callee function for debugging.

    • The value of expressions can be shown at the end of the line like in the Inventing on Principle talk
    • This would give a clear overview of the execution and should make it easy to pinpoint the line where the bug originates.
    • That specific line can then be right clicked to go to the actual function.
    • Having to jump around between different functions and files is unnecessary and makes it difficult to see the forest through the trees.

  • "Error mode" where the editor jumps you to the next error

    • Similar in theory to diff tools that jump you to the next merge conflict

  • dependency recommendation