[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: find-file-project
From: |
Dmitry Gutov |
Subject: |
Re: find-file-project |
Date: |
Wed, 20 Jan 2016 04:47:31 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
On 01/20/2016 04:32 AM, Stefan Monnier wrote:
Hmm... can't remember exactly what were the problems. I think it had to
do with my desire to reproduce the exact same behavior as the old
filecache.el.
FWIW, see the current diff I have.
Were you going to attach it?
Alternatively, a "native" company backend can
return a cons value with a fake "length" to compare against the latter
variable's value (or t, to mean that the check will succeed). I've recently
accepted a patch adding a similar capability to company-capf, on github:
https://github.com/company-mode/company-mode/pull/450.
Good, so we should be able to do it within nxml's capf.
Yup.
Not sure in general (e.g. for attributes), but for tag names at least,
I think that's pretty much the case.
Attribute values could be a problem, but why not in attribute names? Do
we expect to work with freakish schemas, with thousands of possible
attributes?
Not sure what you mean by "complex enough": do you mean "flexible enough
that we don't need a new mechanism", or "so complex that adding yet
another method would make them really unbearable"?
The latter. =/
But that's a bit of a separate concern: since completion-try-completion and
completion-all-completions are on a higher level, I think *they* could be
generics, whereas the all-completions/etc could stay as they are.
But the only argument they receive is the completion-table, so we need
them to be "dispatchable".
They who? completion-try-completion and the other? The default method
will handle lists/alists/hash-tables and functions. The specialized
methods will handle "dispatchable" types.
[ Side note: I've been toying with the idea of "callable objects", by
which I mean thingies which have slots and dispatchable types (like
cl-structs or eieio objects) but which can also be passed to funcall.
We could use them for the advice objects of nadvice.el, for the stream
objects of stream.el, and potentially here as well. ]
Like a closure, but with named fields as its environment? I can see how
it could be handy for debugging, but not how it would help with the
issue at hand.
- Re: find-file-project, (continued)
- Re: find-file-project, John Wiegley, 2016/01/07
- Re: find-file-project, Dmitry Gutov, 2016/01/07
- Re: find-file-project, Stefan Monnier, 2016/01/08
- Re: find-file-project, Dmitry Gutov, 2016/01/19
- Re: find-file-project, Stefan Monnier, 2016/01/19
- Re: find-file-project, Dmitry Gutov, 2016/01/19
- Re: find-file-project, Stefan Monnier, 2016/01/19
- Re: find-file-project,
Dmitry Gutov <=
- Re: find-file-project, Stefan Monnier, 2016/01/19
- Re: find-file-project, Dmitry Gutov, 2016/01/20
- Re: find-file-project, Stefan Monnier, 2016/01/20
- Re: find-file-project, Dmitry Gutov, 2016/01/20
- RE: find-file-project, Drew Adams, 2016/01/20
- Re: find-file-project, Dmitry Gutov, 2016/01/20
- RE: find-file-project, Drew Adams, 2016/01/20
- Re: find-file-project, Dmitry Gutov, 2016/01/20
- RE: find-file-project, Drew Adams, 2016/01/20
- Re: find-file-project, Dmitry Gutov, 2016/01/20