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

Named snippet syntax is confusing #2

Open
svenssonaxel opened this issue Sep 29, 2022 · 2 comments
Open

Named snippet syntax is confusing #2

svenssonaxel opened this issue Sep 29, 2022 · 2 comments

Comments

@svenssonaxel
Copy link
Owner

The named snippet syntax is rather confusing, since a snippet line changes the meaning of other status markers.
For example, depending on what sides have an active snippet, the space status marker can have four different meanings:

  • Present in both old and new file
  • Present in old file and right snippet
  • Present in left snippet and new file
  • Present in the two active snippets

Similarly, one needs to know what sides have active snippets to understand the status markers +, - and _.

@svenssonaxel
Copy link
Owner Author

Proposal:

  • A hunk can have zero or more snippet columns, indicated by that number of ^ characters at the beginning of a hunk header.
  • Snippet lines must have a ^ in exactly one snippet column, spaces in any/all other snippet columns, # as status marker, and then the snippet name. End of snippet is indicated by any snippet line, or end of hunk. As a special case, a snippet with empty name deactivates that column, after which it is illegal to include content for that column using =.
  • Content lines must begin with a number of characters equal to the number of snippet columns in the current hunk. . and = indicate that this content is not and is, respectively, present in the snippet currently active for that column. After this, the content line continues with the status marker, all of which has only one possible meaning.

svenssonaxel added a commit that referenced this issue Oct 1, 2022
Address #2 by changing how named snippets work.

- Named snippet functionality is relegated to special snippet columns,
  which are optional.
- Status markers never change meaning depending on snippet context.
- The hintful hunk header specifies number of snippet columns and
  whether to use newline markers.

This increases not only clarity, but also expressivity:
- An arbitrary number of snippets can be active, and in content lines
  they can be combined with files arbitrarily.
- It is now possible to use named snippets for line-based content
  without using newline markers.
svenssonaxel added a commit that referenced this issue Oct 3, 2022
Address #2 by changing how named snippets work.

- Named snippet functionality is relegated to special snippet columns,
  which are optional.
- Status markers never change meaning depending on snippet context.
- The hintful hunk header specifies number of snippet columns and
  whether to use newline markers.

This increases not only clarity, but also expressivity:
- An arbitrary number of snippets can be active, and in content lines
  they can be combined with files arbitrarily.
- It is now possible to use named snippets for line-based content
  without using newline markers.
@svenssonaxel svenssonaxel reopened this Nov 4, 2022
@svenssonaxel
Copy link
Owner Author

The proposal above is implemented on branch master-syntax2, but this introduces new problems: An unlimited number of concurrently active snippets makes it hard to reason about the format in the general case, and impossible to highlight. The best I could do was to limit the number of active snippets to two in the highlighter. Despite all this, it doesn't even seem to actually become easier to read.

On the main branch master-syntax1, commit 416010f introduces a new highlighting scheme: The background color of the status marker indicates what files the content is present in, but the background color of the content still indicates what sides the content is present on. The idea is that you should be more interested in the sides anyway, since this gives you a more semantic understanding of the differences. If you really want the text-level understanding, you can look at the highlighting of the status markers, or convert to unified format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant