Refactor / improve s:load_libs()

[blueyed]

s:load_libs() should handle errors better.

I think the best approach would be to make it at Python function, and then return in case of errors, e.g. ImportError etc.

Because this requires to indent the whole block, I'd like to get your opinion on this first.

[aliev]

@blueyed may will be better add the debug option, which will disable/enable display the errors. for example:

let g:htmldjango_omnicomplete_debug=0 " enable/disable errors

[mjbrownie]

I was very lazy when creating the s:load_libs section.

There are whole functions that only need to be loaded on the initial use of the complete that are being reinitialised every time you hit the complete key. It would be nice to separate them as well. It won't reload changes to INSTALLED_APPS as well.

As far as adding a big try: except: it's ok as an interim sanity measure. I think I did as much as I could to suppress any warnings but random apps will always throw curve balls. Perhaps a simple command line switch to allow for errors displayed direct or log error output to a temp log file would be great.

A big refactor may involve spinning out the non vim python code into a management command (That reloads like runserver) and acts as a server to a vim (or any editor) client plugin. It would solve a lot of issues and perhaps get a wider uptake. (I really don't know how complete friendly the other editors have been and whether it is worth the effort).

[blueyed]

@aliev A debug option is a good idea, this could be used to not catch the exceptions then.

@mjbrownie Good, I will give it a shot later today.

[aliev]

@blueyed @mjbrownie Hi, guys! :) It seems everyone have forgotten about this bug :)))

[blueyed]

@aliev True.

I have a stash laying around where I basically moved the Python code into pythonx/htmldjangocomplete.py and then just use py from htmldjangocomplete import htmldjangocomplete.

That should provide the current behaviour, but for some reason I've stopped there, and it's probably not enough.

I can see that a management command would be nice, but then I don't know how it would integrate into the current Django instance? It would need to be added to INSTALLED_APPS itself then?!

(sorry if I miss something, just replying from the top of my head)

[aliev]

@blueyed I think it will be enough to turn off messages like:

.env/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py:57: RuntimeWarning: SQLite received a naive datetime (2015-09-10 21:43:38.616467) while time zone support is active.
  RuntimeWarning)

from vim

Grabbing html indent for line: 20
Error detected while processing function htmldjangocomplete#CompleteDjango..<SNR>140_load_libs:
line  331:
/urls.py:10: RemovedInDjango19Warning: Default value of 'RedirectView.permanent' will change from True to False
 in Django 1.9. Set an explicit value to silence this warning.

maybe it would be nice to add something like this?

 #!/usr/bin/env python -W ignore::DeprecationWarning

[aliev]

@blueyed oh:

import warnings
warnings.filterwarnings('ignore',
    '.*',
    UserWarning, RuntimeWarning)

should be work

[blueyed]

@aliev Might be worth a separate PR then?!

btw: https://github.com/mjbrownie/django_completeme (mentioned in this repo's README).

[aliev]

@blueyed alright :)

[aliev]

@blueyed for some reason these methods did not work for me:

import warnings
warnings.filterwarnings('ignore')

and etc...

so, Warning occurred in this part of the code

# Setup Django (required for >= 1.7).
import django
if hasattr(django, 'setup'):
    django.setup()

I've replaced these lines of code:

import warnings
warnings.filterwarnings('ignore',
    '.*',
    UserWarning,)

to

import warnings
warnings.sys.warnoptions = ['-W']

and now module works silently :)

@blueyed @mjbrownie what do you think guys?

[aliev]

@blueyed @mjbrownie created PR: https://github.com/mjbrownie/vim-htmldjango_omnicomplete/pull/6

[mjbrownie]

Great Thanks for that.

[aliev]

@mjbrownie np, thanks you too! :+1: