tomheon / diffscuss Goto Github PK

Namely, covering RTC cases a little better by

• attempting to get the closest line for all candidate source files / lines
• taking the one which actually found the line, and matched closest to the original

E.g.:

B is a reply to A

Reply to A should be below B, not on top of it.

That is they make new lines like

%* %* stuff

This repository contains one or more Emacs-Lisp libraries, which are distributed on Melpa for easy installation using Emacs' official package manager (package.el) and are also mirrored on the Emacsmirror.

This project/repository is about much more than just the elisp libraries. These libraries are tucked away in some "contrib" or "utilities" directory. The maintainers of the project as a whole likely care little about these libraries, which makes it a less than optimal place to maintain them. The maintainers will always have something more important to deal with and potential contributors are likely scared away by the additional processes and conventions that such a large project needs, but which are overkill when looking at the elisp libraries in isolation.

I would like to propose that the Emacs-Lips libraries are maintained in a separate repository. Doing that would solve a few issues and have additional benefits:

• Distributing a package that originates in such a large repository puts additional strain on the Melpa server. Fetching the repository takes longer and they require more space. We are already trying to deal with the latter, but not very successfully and this leads to special-cases in the tooling, which come with additional maintenance costs. See melpa/melpa#5361, also for some past discussion.

• I also maintain the Emacsmirror and here the costs are much higher than for Melpa. The Emacsmirror does not just distribute installable snapshots of a package, as Melpa does.

  Instead it mirrors the upstream repository. But in cases like this, where the repository contains much more than just the elisp libraries, it filters the history, using tools such as git filter-repo and git subtree. Unfortunately these tools are not very reliable and highly inefficient when continuously rewriting large repositories like this one.

  Currently this affects just 33 out of 8485 on the Emacsmirror, and the disproportionate amount of work that it takes to maintain the tooling for these special-cases is just not worth it. So I have decided to phase out support, but not before making an effort to get as many of these Emacs package slit out of the repositories they are currently being maintained in.

• For maintainers of this repository any issue about the elisp libraries is likely just more noise. They have better things to do.

• On the other hand, the original authors of the elisp libraries and people who have contributed to them, likely have notifications for this repository disabled because they only contribute to the elisp parts and there would just be too much noise otherwise. So issues and pull-requests by users are likely to go unnoticed for a long time.

  The author and contributors likely have to be explicitly summoned, as I am doing now: @tomheon @dmilstein @codemac

• Potential contributors are discouraged when their pull-requests are being "ignored" or they might be discouraged by the additional requirements imposed by the project as a whole, and not even try to contribute as a result.

• Users who install elisp packages by manually cloning their repositories and then manually adding the appropriate directories to the load-path, are forced to clone a huge repository just to get their hands on a few elisp libraries in some subdirectory. (Or they can use the filtered repositories on the Emacsmirror, but as I mentioned, those are going away.)

So in summary, I think there are many downsides to maintaining the elisp libraries in this repository. I am not sure there are any upsides, except that it is the status quo.

Moving the elip libraries out of here is some work, that someone has to do, but most of that work is already done. You can just clone the respective repository from the Emacsmirror (at https://github.com/emacsmirror/diffscuss-mode) and publish it somewhere else. (Please check that no recent history is missing and if the mirror repository is not uptodate, then ping me.)

Once you have done that tell me about it here, and I will take care of updating Melpa and the Emacsmirror.

Thanks for considering!
Jonas

Hi,

Would it be possible to relax the definition of a header and body as follows:
Headers should match ^#\*([^\s]*\*)?\s.*$ while bodies should match ^#-([^\s]*-)?\s.*$.

This would keep backwards compat as well as allow the following:

#* author: ejorgensen
#- I'm a top-level comment.
#*|* author: bsmith
#-|- And I'm a reply.
#*|*|* author: sjones
#-|-|- And I'm a reply to the reply.
#*|* author: jkidd
#-|- And I'm a second reply to the original top-level comment.
#* author: mdarks
#- And I'm another top-level comment.
#*|* author: lbutterman
#-|- And I'm a reply to the second top-level comment.

So that, by default, they're listed top-to-bottom in chrono order

At the very top of the file.

And note this in the docs.

E.g. say Matt creates a diffscuss file, and Edmund writes the first review, so at the top it looks like:

%*
%* author: Matt Papi
%*
...
%**
%** author: Edmund Jorgensen
...

Say a third person (say Dan), wants to add a new top-level comment (because he has now reviewed it). If he does C-c C-c in Edmund's comment, he ends up replying to it. If he does it in Matt's top-level comment, Dan's new comment appears above Edmund's, which feels wrong (because Edmund has the mighty First Post).

My instinct is that, if Dan does C-c C-c with point inside Edmund's comment, he should get a new reply to Matt's comment, below Edmund's -- and that diffscuss-mode can look at the usernames to distinguish between Dan and Matt (because Matt would actually want a reply to Edmund by default).

This may be a case of being Too Clever, in which case, feel free to tag it as such an archive it.

Just done through symlinks:

E.g. codereviews dir with:

• reviews
• reviewers

Under reviewers would be e.g. "edmund," which would contain relative symlinks to reviews in reviews.

Could also be a group, e.g. "qa", which could contain either "edmund.user" files, indicating edmund was a member of the group, or "someothergroup.group", which includes a whole group.

Under reviews is an archived folder.

Scripting support for:

• requesting review from x, which means resolving if a group, adding a symlink in each mailbox (not putting it in the group folder).
• bouncing a review to someone, which means removing from your mailbox and putting in someone else's.
• removing a review from your mailbox (presumably because you're done).
• archiving a review, which also removes all symlinks to it.

Loved that feature of post-review. Maybe instead of being, like, a piece of diffcuss in elisp, it's a command-line tool that you basically give a git range to, and it outputs the diff for that range, prepended with a message concatenating all the commit messages. That would be pretty easy to write, I would imagine, and would nicely smooth out the workflow I'm slipping into:

• Make a commit
• git diff HEAD^..HEAD > codereviews/some_name.diffscuss
• Edit that to add a header of some kind, possibly pasting in the commit messages
• git add codereviews/
• git commit --amend to get it all into the same commit, which I find quite satisfying
• git push

If instead I:

• Make a commit
• gen-diffscuss HEAD~1 > codereviews/some_name.diffscuss
• Edit the embedded commit message
• Otherwise, the same

That feels like a small, nice win.

The default python on my Macbook is python2.4, which failed (for like, the with block, I think). Not sure the best long-term way to fix this, but the short term modest effort would be, I think, to have find-local-source.py check the version and return some specific error code for a too-early python, and then have diffscuss-mode.el report that specific issue back to the user, via the minibuffer.

I fixed short-term by just adjusting the #! line in find-local-source.py, to point to python2.7.

As discussed on hacker news (https://news.ycombinator.com/item?id=7973832), many people feel that diffscuss should overload diff comments for its own purposes, rather than inventing its own syntax and breaking compatibility with the diff format. The only reason that was given against embedding diffscuss markup inside diff comments is that it would confuse the diffscuss parser in case unrelated comments are already present in the diff; this is easily solved by using a special beginning-of-line character inside diff comment blocks. In the proposed new format, "normal" diff comments would start with #, while diffscuss comments would start with #%* and #%-. In order not to break compatibility with existing diffscuss files, diffscuss (and its plugins) can still support the old syntax in read-only mode, but should use the new one by default when generating diffs.

For latest on format (including coding / hash headers)

For gh-export

For dmb

For getting set up / started with emacs / vim

I think the right rules for a first cut are probably something along the lines of:

• find the git repo root to compare paths against
• prefer the new path, fallback to the old path
• find any lines matching the closest new line if new path, old line if old path
• if one such match, jump to it
• if multiple such matches, jump to the closest one by calibrated line number
• if no such matches, jump to the line number

The editor module has basically no test coverage.

http://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

"Don't define C-c letter as a key in Lisp programs. Sequences consisting of C-c and a letter (either upper or lower case) are reserved for users; they are the only sequences reserved for users, so do not block them."

GNU Emacs now has several supported package repositories. By making diffscuss available would mean that users would merely need to select it from a list to install it, and updates can be easily automated. ELPA is the default repository run by the GNU project, but there others with smaller audiences (but fewer requirements).

Jumps past the new thread.

Current idea: add a function to prefix a region as a diffscuss comment, so that you can, after pasting it in, just mark the region and then prefix it. (Of course, this could run into issues with indented comments, but would be a good start).

Other option: take over pasting behavior, somehow.

Currently, diffscuss has an experimental import of github issues into a diffscuss mailbox.

What would be truly awesome is the following:

• Multiple backends: native git, gerrit, github, bitbucket/stash.
• Multiple frontend: emacs, vim, ???
• Multi-project mailbox: diffscuss mailbox

The problem is that the mailbox code right now assumes it's part of your git repository, which makes diffscuss an all or nothing choice.

Things that probably need to change to truly support an "offline review system":

• diffscuss mailbox support a separate, multi-project, mailbox (think: ~/.config/mailbox) that is not tied into an individual git repo. I would implement it as another, separate, local-only git repo.
• a configurable mailbox sync activity, which each backend would need code to support. The current sync is essentially "native git" and we could leave that as a null-sync, and then use git magic to manage it.

Get it off stdout unless requested, give a fair amount of detail.