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

Menu system is confusing and unhelpful #70

Open
tngreene opened this issue Feb 16, 2018 · 6 comments
Open

Menu system is confusing and unhelpful #70

tngreene opened this issue Feb 16, 2018 · 6 comments

Comments

@tngreene
Copy link

Last up. And let me just say thank you for maintaining this. As a maintainer of an open source project, I know this is not easy.

Lastly, though some of the commands aren't working, I'm still able to try working through the menus. They were confusing to me and only after carefully reading the manual do I have a better feeling of what they might do, as the manual is not comprehensive.

These were my first impressions before I read the manual.

0. search
1. cancel
2. batchset
3. unsure
4. in_hierarchy
5. resources

What does search mean? Search what? Aren't the others also searching something? What will "unsure" do? Does "in_hierarchy" refer to the folder heirarchy? Does resources refer to something in the .ropeproject folder?

And the rest of the full log:

Rope project root folder: .Opening [.] project ...
Opening [.] project ... done
0. search

  1. cancel
  2. batchset
  3. unsure
  4. in_hierarchy
  5. resources
    Choose what todo: [search] 40. yes <-Not sure what 40 means. Number of occurrences? We're done? Didn't I already choose what to do?
  6. no <- If there is only one choice, why give me the choice?
    Rename methods in class hierarchy: [no] 10. search <- Woah! Rename? I thought I was just finding information!
  7. cancel
  8. batchset
  9. unsure
  10. in_hierarchy <- These options are repeated, but I'm not sure how it is relativent, if we've already searched through everything and found 40 of something.
  11. resources
    Choose what to do: [search] Find Occurences ... <- Now we're finding occurrences?! What was the rest of this for? What have we been doing?
    Find Occurrences ... 5%% <- Before this appeared, I thought the program had completely crashed Vim, but it turns out that it was just taking forever to do whatever it is it is/was doing. I was completely surprised to find out it was not dead in its tracks.
    Find Occurrences ... 10%% <- I keep thinking that this is dead, but every 10 minutes or so another 5% gets added. I'd love to see how long this takes, but I can't wait that long.
So, some real feedback

- Having more descriptive names would be useful
- The pattern of "Go through a tree of menus, getting returned to the base prompt after each time" was very unintuitive. A indicator of how many more menus to go through or progress bar would be helpful.
- Also, why not a series of prompts to work through like a flow chart? Why keep going back to the base prompt?
- Though a small detail, having consistent new lines, spacing and properly putting spaces between things, the careful printf stuff, would have made a more readable and better flowing menu tree. Being careful and consistent means you can take advantage of a pattern like
    - "A new line always means a new action occurred"
    - "A line that ends in ... means the computer is thinking"
    - "A line that ends in a question mark means the user should be thinking"
    - "Text formated in "Title Case With Spaces Ending With A Colon:" means a user choice, not data, paths, or future code changes. 
- ASCII Art is your friend! The NERDTree Menu is a great example of making UI out of text that stands out from all the other text around it, making it much easier to pay attention to.
- For a long operation use an animated progress bar and tell a way to cancel it. Hopefully, canceling the operation would rollback changes.
- Warning what could mutate the contents of a file would give more confidence before proceeding.

Now, I know this is all easier said and done, and any time someone says "just do X, it is so easy!" they're probably have no idea what they're talking about and asking for, especially for a volunteer project, and this is already a lot of work put into this so far, but! I have really high hopes for this project!

If I could do some refactoring in Vim I could ditch PyDev and Eclipse! So, I'm really hoping that this project becomes usable. I expect nothing, and will be glad for whatever else comes out of the python open source community. But maybe if this becomes especially useful in my life, I could put in a few pull requests to help out the community!
@tngreene
Copy link
Author

Oh, I should also say, I assume you've already had many of these thoughts yourself. I couldn't find a "TODO" list anywhere, so, maybe there is some cross over.

@mcepl
Copy link
Contributor

mcepl commented Feb 17, 2018

I completely agree that menu is mess. Two answers:

  1. Any specific suggestions how to fix this would be welcome (especially in the form of pull request).

  2. I am not certain how much future there is for whole ropemode and ropevim. Currently it is still the best way how to use rope in your application, but there seem to be better alternatives developing. rope itself seems to be everywhere (e.g., inside of the Python extension for VS Code and others), but as the future goes I would bet more money on something like LSP and its (still very immature) vim plugin (other implementations could be found elsewhere).

@Palpatineli
Copy link

Hi mcepl,

What you suggest sounds like a great way forward, but it may actually be an open niche now. The palantir python lsp is a hack that bundles together rope/jedi/flake8/etc and there are a lot of problems with that, including duplicate messages and non-incremental check in many of its components. PyDev is currently tightly bundled with vscode. There is another alpha phase project on github that is not working.

All this been said, is there a plan to convert rope itself into a lsp for python, as rope basically does everything already and just needs an interface?

@mcepl
Copy link
Contributor

mcepl commented Apr 4, 2018

I agree about pyls, but it seems to be moving in the more modular direction. And it is not necessarily too important anyway: if this particular LSP server turns out to be wrong, it can be replaced by something else (e.g., I can imagine a fork having true rope etc. as a git submodules).

And BTW PyDev is plugin to Eclipse … oh they made it to work with VS Code as well. Interesting. For VS Code itself I meant vscode-python which uses rope as well.

Concerning converting rope into the LSP server, I think a separate project on the top of rope is more likely to work (hence possible fork of pyls or something similar to ropemode/ropevim/ropemacs).

@samyak-jain
Copy link

@mcepl There's an open issue for having better integration with rope in pyls. Might be easier to integrate all the good stuff of rope into pyls than create a whole new language server.

@mcepl
Copy link
Contributor

mcepl commented Mar 14, 2021

I have started my own clone of pyls, where I try to use rope only, but I don't have enough time for it, so it is now mostly abandoned. Any pull requests are more than welcome.

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

4 participants