company 0.4 -- extensible inline text completion mechanism

[Nikolaj Schumacher-2]

Company is a modular completion mechanism.

This version brings a few bug fixes and the following features:


The dabbrev back-end now searches other buffers, but with a
user-specified time-limit.

There is a new dabbrev variant specifically for code.  It searches for
symbols instead of words and skips comments and strings.

Completions from multiple back-ends can now be merged.  For example, it
is possible to combine the candidates from etags (for global symbols),
dabbrev (for local variables) and language-specific keywords.



All this should make company much more suitable for languages not
supported by CEDET, e.g. Python.

As always, the latest version is available at
http://nschum.de/src/emacs/company-mode/

and should also be on ELPA (http://tromey.com/elpa/) soonish.

regards,
Nikolaj Schumacher


_______________________________________________
gnu-emacs-sources mailing list
gnu-emacs-sources@...
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources

[Ralf Schmitt-2]

Nikolaj Schumacher <me@...> writes:

>
> All this should make company much more suitable for languages not
> supported by CEDET, e.g. Python.
>

I'm attaching some code which makes company use rope in python mode.
It's based on code found on the emacswiki which did the same for
autocomplete mode. I'm setting company-minimum-prefix-length to 0 in
order to get completions after a dot like in "self.". It depends on rope,
ropemacs and pymacs being installed.

(require  'company)

(autoload 'pymacs-apply "pymacs")
(autoload 'pymacs-call "pymacs")
(autoload 'pymacs-eval "pymacs" nil t)
(autoload 'pymacs-exec "pymacs" nil t)
(autoload 'pymacs-load "pymacs" nil t)

(defvar company-python-ropemacs-loaded nil)
(defun company-python-ropemacs-require ()
  (unless company-python-ropemacs-loaded
    ;; Almost people hate rope to use `C-x p'.
    (if (not (boundp 'ropemacs-global-prefix))
        (setq ropemacs-global-prefix nil))
    (pymacs-load "ropemacs" "rope-")
    (setq ropemacs-enable-autoimport t)
    (setq company-python-ropemacs-loaded t)))

;; (company-python-ropemacs-require)

(defun company-python-prefix-list-elements (list prefix)
  (let (value)
    (nreverse
     (dolist (element list value)
       (setq value (cons (format "%s%s" prefix element) value))))))


(defun company-python-prefix()
  (interactive)
  (if (and (derived-mode-p 'python-mode) (fboundp 'rope-completions))
      (if (looking-back "\\_<[a-zA-Z_]+\\_>")
          (match-string 0)
        (if (looking-back "\\.")
            ""
          ))
    nil))

(defun company-python-candidates()
  (interactive)
  (when (fboundp 'rope-completions)
    (let (
          (prefix (company-python-prefix))
          (completions (rope-completions))
          )
      (company-python-prefix-list-elements completions prefix)
      )))


(defun company-python-backend (command &optional arg &rest ignored)
  (case command
    ('prefix (company-python-prefix))
    ('candidates (company-python-candidates))
    ))

;; (add-to-list 'company-backends 'company-python-backend)

(provide 'company-python)






_______________________________________________
gnu-emacs-sources mailing list
gnu-emacs-sources@...
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources

[Bo Lin-5]

Nikolaj Schumacher <me@...> writes:

> Completions from multiple back-ends can now be merged.  For example, it
> is possible to combine the candidates from etags (for global symbols),
> dabbrev (for local variables) and language-specific keywords.

Here's a little feature request. Instead of merging completions from
multiple back-ends, can you provide a command
'company-try-next-backend', which basically discards all the current
completion candidates and pass control on to the next back-end in the
list? Ideally the back-end list could be treated like a circular ring,
cycling back to the first one when falling off the end.

An example. Say I bind M-/ to company-manual-begin, and
company-backends is '(A B). I press M-/ to request completion, and get
a list of candidates from A. Now currently (correct me if I'm wrong) if
A decides it can handle it then B will never be tried. With my proposed
'company-try-next-backend', which I will bind to M-/ in
company-active-map, then I can press M-/ again to discard everything
from A and get a list of candidates from B.

Thanks,
Bo


_______________________________________________
gnu-emacs-sources mailing list
gnu-emacs-sources@...
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources

[Nikolaj Schumacher-2]

Bo Lin <bo@...> wrote:

> Here's a little feature request. Instead of merging completions from
> multiple back-ends, can you provide a command
> 'company-try-next-backend',

It sounds like a good idea.  If it works well, I'll try to get it into
the next version.


regards,
Nikolaj Schumacher


_______________________________________________
gnu-emacs-sources mailing list
gnu-emacs-sources@...
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources

[kevin5jan]

Hello,

I've been trying to use company-mode for java programming, but cannt get a completion output. I've downloaded CEDET and also tried with GnuGlobal. What is the exact setup for .emacs file to run company-mode for java? BTW I dont see completion options for .cpp files either.

Cheers

Kev

Nikolaj Schumacher-2 wrote:

Company is a modular completion mechanism.

This version brings a few bug fixes and the following features:


The dabbrev back-end now searches other buffers, but with a
user-specified time-limit.

There is a new dabbrev variant specifically for code.  It searches for
symbols instead of words and skips comments and strings.

Completions from multiple back-ends can now be merged.  For example, it
is possible to combine the candidates from etags (for global symbols),
dabbrev (for local variables) and language-specific keywords.



All this should make company much more suitable for languages not
supported by CEDET, e.g. Python.

As always, the latest version is available at
http://nschum.de/src/emacs/company-mode/

and should also be on ELPA (http://tromey.com/elpa/) soonish.

regards,
Nikolaj Schumacher


_______________________________________________
gnu-emacs-sources mailing list
[e-mail]
http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources