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

How reliable is quickcursor supposed to be? #30

Open
franciscolourenco opened this issue Jun 7, 2012 · 16 comments
Open

How reliable is quickcursor supposed to be? #30

franciscolourenco opened this issue Jun 7, 2012 · 16 comments

Comments

@franciscolourenco
Copy link

About half of the times the text is not pasted back the the source application.
It's very unreliable.
What's your experience?

@GreyBurkart
Copy link
Collaborator

Could you give me a bit more information on your setup? With a compatible "edit in" app it should be pretty reliable most if not all of the time. Where do you usually pull from, and into what app (and which version)?

One known exception would be text fields in Java Runtime Environments, such as Eclipse IDE.

@franciscolourenco
Copy link
Author

Mac OS X 10.7.4
QuickCursor 2.6
Sublime Text 2 build 2195
It happened a few times with Chrome, Notational Velocity and Xcode.

@franciscolourenco
Copy link
Author

@GreyBurkart
Copy link
Collaborator

I'll add it to our bug list regardless, but if the text is having trouble getting back to the original location, that's a sign that the ODB pipeline from the "Edit In" app itself isn't sending reliably. If the same process works reliably with other editors like TextWrangler or MacVim, then that would be my first guess.

ODB support was added in Sublime build 2187, if I remember correctly, but hasn't made it into the official 'production' version yet. This could be due to ODB Suite configuration issues on the side of the Edit In application (ST2 build 2187+).

One other possibility, from an example with tabbed browsers: QuickCursor can lose focus if browser tabs are switched between the point where QC grabs the text to be edited and shuttles it back to the original location. We haven't found a workaround for that. That seems less likely given that ST2 is used as the "Edit In" app, not the source app, but worth mentioning just in case.

@danielhopkins
Copy link

I'm on the same things. I'm definitely willing to believe that this is Sublime's fault but it's hard for me to debug. Are there any debug switches we can turn on in Quick Cursor to see if it's getting back the correct information?

@danielhopkins
Copy link

(I mean version of OS / ST2, etc)

@GreyBurkart
Copy link
Collaborator

@jessegrosjean are there any extra debug flags to enable?

QC tends to be rather prolific when outputting to the Console (at least when I build & run in Xcode), and ODB errors usually show up there.

@franciscolourenco
Copy link
Author

QuickCursor can lose focus if browser tabs are switched between the point where QC grabs the text to be edited and shuttles it back to the original location.

Can I switch from the edit in app and come back without breaking QC?

@GreyBurkart
Copy link
Collaborator

With the exception of 'don't change the focus of the source app/text field/document' yes, flip around to other apps. When you go to paste back the edited text, QuickCursor is still looking for the same conditions as it left in the source app.

This would cause problems in the source app, for example:

  • Changing tabs in a browser before sending the text back
  • Closing or switching to another document in a word processor before sending the text back

This shouldn't cause problems:

  • If you're not using a text field on a webpage as the source, opening up a browser and doing research
  • Referring to other text files or PDFs (etc) in another app

@jessegrosjean
Copy link
Owner

No, there are no extra debug flags that I know about it. If you really want to debug something I think best is to run it in Xcode and debug that way.

@danielhopkins
Copy link

I noticed that there seems to be different behavior with the command "Close File" vs "Close Window". The former might be more reliable.

@danielhopkins
Copy link

I haven't been able to find any debug output in console. What log files does Quick Cursor write to?

@jessegrosjean
Copy link
Owner

I mean debug with Xcode breakpoints, I don’t think QuickCursor does much if any logging.

@wturrell
Copy link

Just to add, I've found it somewhat intermittent as well, especially using Google Chrome and Macvim.
It's still safe providing you have an app that keeps a Clipboard History (e.g. Launchbar) - then if you do close the document in your text editor and nothing happens you can just insert the second most recent item from there.

@franciscolourenco
Copy link
Author

I have problems mainly google chrome as well.
Good to know about the clipboard though.. :)

@xiongchiamiov
Copy link

Chrome+Macvim seems to work about half the time for me. I just reopen Macvim, reopen the file (from recently-opened list), and use the system clipboard when this happens.

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

6 participants