Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Highlight the background of important code #1116

Closed
galeyang opened this issue Jun 12, 2019 · 5 comments
Closed

Highlight the background of important code #1116

galeyang opened this issue Jun 12, 2019 · 5 comments
Labels
closed-obsolete Closed as the reported issue is no longer relevant from-study Issues are filed from a research study P1 A high priority bug; for example, a single project is unusable or has many test failures type-ux A user experience or user interface related issue
Milestone

Comments

@galeyang
Copy link

galeyang commented Jun 12, 2019

When creating the new Future codelab, @legalcodes and I would like to have a way to highlight the important code. This feature is useful in the demonstration use case.

Goal:

  • As a codelab author, I want to highlight code/text without compromising its testability and readability.
  • As a codelab learner, I want to quickly identify the important info in the demo code.

Example from CodeMirror
https://codemirror.net/demo/markselection.html
image

Example from flutter.dev
image


Status of this issue is also tracked in https://github.com/orgs/flutter/projects/3.

@galeyang galeyang added the type-ux A user experience or user interface related issue label Jun 12, 2019
@legalcodes
Copy link
Contributor

I'm adding this to go/dartpad-tracker as well

@galeyang
Copy link
Author

More notes from the previous workshop

@kwalrath If we want to do this, current website uses
https://github.com/dart-lang/site-shared/blob/master/doc/code-excerpts.md
It'd be nice to be consistent

I'm not sure if flutter.dev and dart.dev use same infra now.

@RedBrogdon How might we highlight lines within the editor for better comprehension?
What happens if the user adds a line above the lighlight?
Or deletes the line?

The CodeMirror approach makes sense to me.

@RedBrogdon
Copy link
Contributor

Just talked this over with @legalcodes and @johnpryan. We came to the following plan of action, which can be implemented in separate PRs and deployed over time:

  1. Add a mechanism for a parent to send messages into the DartPad iframe with line and character indices to highlight. As long as the user hasn't edited the code from its original state, DartPad will highlight those lines. Once they begin editing, the highlights will disappear.

  2. When a call to highlight comes in, if the code is in a dirty (edited) state, display a popup that says the user needs to reset the code (using the existing reset button) in order for highlights to work.

  3. (stretch) Investigate whether we can use the dart-services analyzer to do something as cool as locate a code element (all instances of a particular keyword or a particular class/method by name) and return its location in the code. With that, we could add a second message type parent pages can use to ask DartPad to highlight individual code elements without needing to specify their exact location.

@RedBrogdon RedBrogdon added the P1 A high priority bug; for example, a single project is unusable or has many test failures label Jun 13, 2019
@devoncarew
Copy link
Member

If it helps, the analysis server does support an outline event. It's used to power the outline views in IDEs. It includes info about the structure of a compilation unit (classes, methods) as well as their source ranges.

@RedBrogdon RedBrogdon added the from-study Issues are filed from a research study label Jun 26, 2019
@RedBrogdon RedBrogdon added this to the Backlog milestone Jul 24, 2019
@parlough
Copy link
Member

As part of the new, simplified version of the DartPad frontend, the exercise and multi-file functionality this was related to was removed.

If anyone would like to see similar functionality brought back, please check out #2702 or open a new issue. Thanks so much!

@parlough parlough closed this as not planned Won't fix, can't repro, duplicate, stale Jun 16, 2024
@parlough parlough added closed-stale Closed as the issue or PR is assumed stale. closed-obsolete Closed as the reported issue is no longer relevant and removed closed-stale Closed as the issue or PR is assumed stale. labels Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-obsolete Closed as the reported issue is no longer relevant from-study Issues are filed from a research study P1 A high priority bug; for example, a single project is unusable or has many test failures type-ux A user experience or user interface related issue
Projects
None yet
Development

No branches or pull requests

5 participants