Differences between revisions 20 and 21
Revision 20 as of 2018-08-27 17:57:25
Size: 6943
Editor: GregorySzorc
Comment: source transforming module importer for python 2.7
Revision 21 as of 2018-10-13 07:43:13
Size: 7022
Editor: GregorySzorc
Comment:
Deletions are marked like this. Additions are marked like this.
Line 99: Line 99:
A proof of concept for this exists at https://phab.mercurial-scm.org/D5052.

/!\ This page is primarily intended for Mercurial's developers.

Good Ideas for Enhancements

Ideas that the community has discussed and largely approved of, but no one has yet implemented. This is somewhat distinct from Plan pages, although the two lists may overlap.

Projects listed here may be a good starting point for new contributors wanting to take on a more significant contribution than fixing "easy" bugs, without having to take on an up-front design discussion.

1. Expect Revset

expect(<set>, <int>) revset: fails if <set> isn’t exactly <int> elements

expect(<set>, <min>, <max>) revset: fails if <set> isn’t exactly between <min> and <max> inclusive

one(<set>) alias for expect(<set>, 1)

This then allows an alias for hg next to be update -r one(children(.)) with sane failure behavior, and also makes some other scripting tasks a little less difficult.

2. hg shellprompt

hg shellprompt bash "{branch} {node|shortest}": emits string for eval in bash to efficiently produce the specified template. Opens the door to first-part native prompt helpers that don’t have to start a Python. Prior art in docker’s command line tools?

Notes from the 4.4sprint on this topic:

  • FB has scm-prompt.sh in fb-hgext/scripts/ (demoed by Ryan)

  • Commonly requested feature: status. Too slow to include though
  • Possible solutions: async zsh prompts; watchman-push updated prompt simple dict file in .hg (could also be cronned or only updated when hg commands are run)
  • Kevin likes the template language for "hgprompt" (author: sjl on bitbucket). Idea: have extension print out some shell code that could be evaled. Since it's owned by mercurial, it can do things the "best" way given the current mercurial release (eg, in a future with minimal startup time, could be an hg command, but for how could be something more similar to scm-prompt.sh)

https://github.com/jonathanslenders/python-prompt-toolkit is also worth looking into.

3. Make `hg grep` do what people expect

See GrepPlan for details. Not a small project, but would be greatly appreciated by many users.

Update May 18, 2018: Sangeet Kumar Mishra is working on this as part of his Google Summer of Code project.

4. Make -S/--subrepos flags unnecessary

It has always been the intention to make commands like hg status, hg add, hg remove, etc. handle subrepos transparently. The way to go about that is outlined here; status of this work was being tracked on SubrepoWork.

5. Sensible merge diffs

Mercurial shows diffs against the first parent for all changesets, including merges, unless explicitly instructed to show the diff against the second parent. It would be better if we could show only the changes which were made to resolve conflicts. Unified diff by definition can only show the differences between a parent and a child revision, but both Git's merge diff and the now-unmaintained MergediffExtension extend this by adding a second column of +/- annotations on each line.

It's possible we could even do better, by showing only the changes that were made to resolve conflicts (something like a diff between the mechanical merge output and the actual committed code). This would save users from needing to learn to read an even more complicated format than unified diff.

6. .mailmap support

Git supports a .mailmap file that can be used to map author names and email addresses to new values. For more info, see https://github.com/git/git/blob/5be1f00a9a701532232f57958efab4be8c959a29/Documentation/mailmap.txt.

Mercurial could likely support mailmap files relatively easily. Implementing it at the templating layer to rewrite author fields would be relatively easy. Implementing it in revsets is also pretty reasonable. Wiring it in to the changeset level is a bit more complicated since that could influence e.g. history rewriting. It probably lives in the revset and templating layer.

Update April 5 2018: mailmap is available as a template function, see https://www.mercurial-scm.org/repo/hg/file/2a2ce93e12f4/mercurial/templatefuncs.py#l173

(Note: This mapping is similar to 'hg churn' aliases file functionality.)

7. `hg bundle` remote server support

It should be possible to use hg bundle against a remote server. This would convert the arguments into a getbundle wire protocol call and stream the emitted bundle to a local file.

8. curses merge tool

We have a curses interface for interactive commit. We should add a curses interfaces for merge conflict resolution.

9. Interactive revset prompt

Allow users to type a revset and see the results in real time via a curses interface. Also warn them about unexpectedly slow revsets (like date(...)).

10. Dry-run everywhere

Add -n dry-run functionality to many commands. Ex: rebase and histedit could print the smartlog that would result if it ran.

Update May 18, 2018: Sushil Khanchi is working on this as part of his Google Summer of Code project.

11. Side-by-side diff/log rendering

Allow rendering side-by-side comparisons. I.e. vertical split diff views; side by side smartlog comparisons

12. Interactive blame explorer

Curses UI that allows exploring the blame of a file (i.e. going to a line, hitting left and going to the previous version of that line)

13. Move our wiki to better place or improve the current wiki style

mpm was in favor of having of better styled wikis and we should do that for various purposes.

14. Source Transforming Module Importer for Python 2.7

We use a custom Python module importer on Python 3 to ease porting efforts. See also https://gregoryszorc.com/blog/2017/03/13/from-__past__-import-bytes_literals/.

We should consider doing something similar for Python 2.7. We would build a custom module importer that recognizes the Python 3 token stream and normalizes it to a Python 2.7 compatible token stream. This would be similar to https://github.com/nvbn/py-backwards except the transformation would be performed at import time instead of require a pre-execution source code compilation step.

Having a module importer that recognizes the Python 3 token stream would allow our source code to use Python 3 features. Notable features include type annotations and yield from. We could also rewrite items() to iteritems(), perform other transformations that make sense to ease porting efforts.

This would likely require vendoring copies of Python 3's tokenize.py and tokens.py from the standard library, as we'd need to use Python 3's tokenizer on Python 2.

A proof of concept for this exists at https://phab.mercurial-scm.org/D5052.

15. See Also


CategoryDeveloper CategoryNewFeatures

WeShouldDoThat (last edited 2018-10-13 07:43:13 by GregorySzorc)