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
ref/cite completion: fixes and enhancements #120
Conversation
…e ref/cite dispatcher more tolerant of allowed formats
…context is appropriate i.e., if the cursor is immediately preceded by "\ref" or "\cite" or recognized variants.
… unnamed file scenario
…ommand into a function used by both.
… function. Also, fixed a few corner cases along the way.
…s (shouldn't actually change what is/isn't matched)
…ept more of the forms that the completion functions internally accept.
…es as used in the ref and cite completion functions.
…quick panel from working except at the start of a line.
…et to true, stops { and , from automatically opening the ref/cite completion quick panels.
THis looks amazing! I really have very little time these days, but this My only issue is that I prefer small, atomic commits rather than one big On Mon, Dec 10, 2012 at 4:02 PM, Wes Campaigne notifications@github.comwrote:
Marciano Siniscalchi |
Thanks! And, yeah, sorry about the size of the change. Almost all of the individual commits are pretty small, but I got on a roll, and they started to stack up. Also, there's no real way to stop a refactoring of the guts of the completion into shared functions (f0ef951 and c544ab8) from showing up as a huge diff, even though most of the code is actually unchanged in both those commits. |
i tested if this resolves Issue #118 and found that it indeed does, also with these patches everything i type is echoed back in the console |
Thanks for the feedback! Regarding the echoing: there's a lot of diagnostic print statements in there. I haven't added any, but I didn't turn any off, either. (They should probably be turned off eventually, though.) It's odd that the '{' trigger is failing. What you're describing implies that the context is matching enough to activate the keybinding (and thus run the completion function), but something in the function must be failing (or hitting an exception) before it gets to the point where a { would be inserted -- and doing so in a way that doesn't generate an error message. I'm not sure what could be causing that. What gets output on the console when this happens? |
i have compared what happens on my windows desktop (which is where the error occurs) with my linux laptop. TEX root: u'/path/to/file.tex' i also tried with a file which does not contain any unicode characters. so basically there seems to be some other error that prevents the command from completing, i will later try with a clean version of sublime, when im back on my desktop. |
…statements) The Sublime terminal apparently only handles ASCII, so printing unicode text to it causes exceptions. So I've disabled several superfluous print statements that can run into trouble there. Also, the ref completion would hit an exception if it read a \label from a file that contained a non-ASCII character. I've added code to check for \usepackage[.*]{inputenc} and, if present, read the file using the appropriate decoder. Similarly, I've added analogous code to the cite completion, although in that case it's only guarding against non-ASCII characters in .bib filenames; the contents of the .bib files are still assumed to be ASCII. This is a tricky problem since the character encoding of .bib files is a messy topic. (And since the bib parsing needs other fixes anyway, it's probably not worth worrying about it too much right now.)
I went through and made some changes that I hope fix a couple issues regarding the handling of unicode characters. This might solve the '{' not appearing issue, but I'm not sure; from what you're saying, there could still be another problem. |
… the completion crashes or fails miserably, at least a { or , should be inserted.
This latest commit should solve the problem of { not appearing, even if I've still missed some other underlying issue that's stopping the completion menu from working. |
i tested it again with the current version and everything seems to work for me now. so i say my thanks. |
…pletion to work for things like \citep[14]{
Yeah, the cite regexes had no awareness of optional arguments to the cite command. 404c0bf fixes that. Thanks for pointing it out. |
It works great with the commit as long as there is only one citation in the paragraph. If there are any other citations before the one I want to add, I get the |
No, everything seems to be working for me. Could you post a text sample for where it's failing? |
Yes, you are right. It was a problem with one of my custom key combinations. I have one that opens the quick select panel when I press |
THhis is all amazing work guys. I promise I'll pull this one way or On Tue, Jan 8, 2013 at 3:13 PM, jlegewie notifications@github.com wrote:
Marciano Siniscalchi |
Does is also solve Issue 134? I writing my own script to fix that (and also show journal name in the search panel), but it does not use regexes (to avoid problems with nested It goes like that (just functions):
|
No, it doesn't really fix the problem. It's still using the quick and dirty regexes to pull out the field values. It DOES avoid the problem of having the wrong author shown, but that's because in the case where there's an entry with no author field, it returns an error and aborts, instead of continuing with mismatched values. Your approach is a much better idea, but there was talking of adding a proper full bib parser, so I didn't do much to change the current parsing code in my patches. |
Good to hear that is fixes "wrong author" problem. :) I wanted to fix it with regex, about observed that it cannot work in general (just, typically, fields does not contain The "clean" solution is just above + actually running it:
However, as it is going to touch the same lines (and Pull request - Response time is non-trivial), I don't want to mess up with your commits (fixing a lot of things). And anyway, we don't need full BibTeX parsing. E.g. I tried https://github.com/ptigas/bibpy but seems to be too slow for our purpose + messes with |
Could you add support for other cross-referencing commands like |
Actually, this branch already does add support for a variety of other cross-referencing commands, including all of the ones you mention. Specifically, it will recognize and autocomplete with any of:
Let me know if there's any I missed. |
This is an awesome addition. Thank you for your work on this. One very minor observation. I find that the "{" trigger would work better with the "," trigger if, after making a selection from the quick view panel following the "{" trigger, the caret stayed inside the closing bracket, instead of ending up outside of the closing bracket as it currently does. Thus, adding multiple citations requires one to backspace to the end of last citation keyword in order to activate the "," trigger. Admittedly, people who do not often use multiple citations may not find this behavior desirable. Given that I use a keybinding specifically to step outside of brackets, however, I find it much easier to skip over a closing bracket if I only want a single citation than to jump back to activate the "," trigger if I want multiple citations. |
Has this been merged into a branch, yet? I was just working on a StackOverflow question where the user had |
@Westacular just a quick heads-up: I'm now finally able to work on the plugin some more! Merging this will be a lot of work, BUT it's actually something I'd very very very much like to use myself! I hope to find some quiet time to do it soon. I may have questions for you. And THANKS!!! |
OK, I couldn't resist and started playing with it :) Right now I'm having the problem that my bibliography (which has grown "organically" over the years, i.e., it's got all kinds of crap, even though it works fine in both bibtex and LaTeXtools) is not parsed correctly. Too bad! I'll look into it. |
Ok @Westacular and @jlegewie , if you check the Westacular-autocomplete branch, you will see my first stab at merging this. The key thing is that my crufty bib file brought up issues with the way we parse bibliographies (you inherited this from my code, so it's my fault...). I have now modified the code in latex_cite_completion.py so as to parse the bib file differently. Basically, as I read the file, I keep track of matches for title, author, year and editor (in case there is no author---common), and then, as soon as I get an "@" with a keyword, I append the current values of title, etc. onto the corresponding arrays (titles, etc.). This way we are guaranteed to always have complete records, or at least placeholder text for missing entries. I also had to fix a couple of minor issues with the year and author regexes. Bottom line: I'd like to experiment with this some more. For instance, the parsing code is now a bit slow (on a slow machine) because it is an explicit iteration. More importantly, I want to use it in my own day-to-day work to see how robust it is. If it passes this "test", I'll merge it into the master branch. Guys, THANK YOU for this AWESOME contribution! You scratched many of my own itches, and the functionality is outstanding! |
Great that you are making progress! Westacular deserves basically all the credit... Which branch are you using now. I might change to it and test as well. Here are some quick notes:
But that are just some thoughts... |
Hi @jlegewie , I followed github's instructions for non-automatically-mergeable patches. I created a local branch on my machine and pulled from https://github.com/Westacular/LaTeXTools.git This was two days ago. Then, I had to integrate the code with some fixes that had already gone into the master branch, etc.---that was all pretty straightforward. All the work (late-evening hacking session) went into the new bibtex parsing code. To see what I've done, get the Westacular-autocomplete branch of the "official" LaTeXTools repository. I'll be working on that one, and if you want to contribute patches, they should go against that. Again, I think it's pretty much in sync with @Westacular 's own fork. Re. speed, I also thought about caching, but we'll see. It turns out maybe I was too pessimistic. I only noticed a slight delay after e.g. entering Re. parser, sure, a complete parser would be nice to have, but not essential ATM. Right now we need to get keyword, title, author and year only. That's easy to do with ad-hoc code. As you will see, the code is pretty easy to read, and it also does the right thing (the old code was a kludge---each line was parsed multiple times, for instance, even in case of a match). Right now the default is the "fancy" one you guys put in, which I love and which will make several users happy! Not to mention the fact that the multi-cite support totally ROCKS! Again, I want to "battle test" this for a couple of days, do a few tweaks, and then merge with the master branch. But, feel free to make suggestions, etc. Do please take a look at my code in the Westacular-autocomplete branch. THANKS! |
@msiniscalchi We are happy to have you back. For me autocomplete from @Westacular works great, even for >1MB I added a few changes to that branch: #207. |
How is performance from my branch with the westacular improvements? |
As I said, for me (Mac Book, 2009) it works smoothly on 1MB |
...and as a side remark "no bib found" is very annoying when bibliography is in the file (as e.g. it is the almost-final version before sending to a journal or posting on arXiv). |
@stared processing in-file bibliographies is going to require separate code, and won't be as neat. The reason is that each \bibitem entry does not follow a pre-specified format, so it's hard (read: impossible) to guess correctly what the author, title, journal, etc. are. However, I guess one can at least list the keywords. @Westacular @jlegewie I've tweaked the code a bit more and have been testing it. If you can also test it, and no issue arises, I'll merge! |
@msiniscalchi I know that the processing is different, so my point is not to implement it (at least for my workflow once bibliography is hardcoded into the tex file, I don't need that much to search it). However, it is ultra-annoying when every time I write I am thinking what is the best way around (I don't want to silence it in every case - silenced errors are annoying). Any ideas? Maybe error msg only when a shortcut is used? |
@stared got it. Now, there is an option to turn of all autocite/autoref completions. I added the following
This should get rid of your problem. @Westacular and @jlegewie I am thinking about removing the "disable_ref_cite_auto_trigger" setting that you allow for in the keybinding, as the above subsumes it. |
@Westacular @msiniscalchi Just now I saw than for some reason wrapping in environment ( |
Can someone else confirm? Everything seems OK here (on Windows; On Fri, Jun 28, 2013 at 3:45 PM, Piotr Migdał notifications@github.comwrote:
Marciano Siniscalchi |
@msiniscalchi At least on the main branch everything works (i.e. both bibliography and double |
I've made a bunch of refinements/refactoring to the ref and cite completion systems:
"disable_latex_ref_cite_auto_trigger": true
to your user preferences.