ikirill / irony-eldoc

irony-mode support for eldoc-mode
29 stars 9 forks source link

Problem with doc on multi-line function call #2

Open ackalker opened 9 years ago

ackalker commented 9 years ago

In my project I have the following multi-line function call:

[...]
#include <linux/input.h>
#include <libevdev/libevdev-uinput.h>
[...]
struct libevdev *dev;
struct libevdev_uinput *uidev;
struct input_absinfo aix = {0, 0, 32767, 0, 0, 1};
struct input_absinfo aiy = {0, 0, 32767, 0, 0, 1};

int err;
int px, py;

int create(void) {
  dev = libevdev_new();
  libevdev_set_name(dev, "test device");
  libevdev_enable_event_type(dev, EV_ABS);
  libevdev_enable_event_code(dev, EV_ABS, ABS_X, &aix);
  libevdev_enable_event_code(dev, EV_ABS, ABS_Y, &aiy);
  libevdev_enable_event_type(dev, EV_KEY);
  libevdev_enable_event_code(dev, EV_KEY, BTN_LEFT, NULL);
  libevdev_enable_event_code(dev, EV_KEY, BTN_MIDDLE, NULL);
  libevdev_enable_event_code(dev, EV_KEY, BTN_RIGHT, NULL);

  err = libevdev_uinput_create_from_device(dev,
                       LIBEVDEV_UINPUT_OPEN_MANAGED,
                       &uidev);
  if (err != 0)
    return err;

  return 0;
}

Irony-eldoc shows documentation for all function calls except libevdev_uinput_create_from_device, where it only shows documentation when point is after dev, or somewhere in the second or third line of the function call. Putting the function call entirely on one line doesn't help, irony-eldoc still shows docs for the function only if point is within the parentheses. In any case, it does show the type of err when point is within that.

ackalker commented 9 years ago

Relevant portion from libevdev-uinput.h:

/**
 * @ingroup uinput
 *
 * Create a uinput device based on the given libevdev device. The uinput device
 * will be an exact copy of the libevdev device, minus the bits that uinput doesn't
 * allow to be set.
 *
 * If uinput_fd is @ref LIBEVDEV_UINPUT_OPEN_MANAGED, libevdev_uinput_create_from_devi
ce()
 * will open @c /dev/uinput in read/write mode and manage the file descriptor.
 * Otherwise, uinput_fd must be opened by the caller and opened with the
 * appropriate permissions.
 *
 * The device's lifetime is tied to the uinput file descriptor, closing it will
 * destroy the uinput device. You should call libevdev_uinput_destroy() before
 * closing the file descriptor to free allocated resources.
 * A file descriptor can only create one uinput device at a time; the second device
 * will fail with -EINVAL.
 *
 * You don't need to keep the file descriptor variable around,
 * libevdev_uinput_get_fd() will return it when needed.
 *
 * @note Due to limitations in the uinput kernel module, REP_DELAY and
 * REP_PERIOD will default to the kernel defaults, not to the ones set in the
 * source device.
 *
 * @param dev The device to duplicate
 * @param uinput_fd @ref LIBEVDEV_UINPUT_OPEN_MANAGED or a file descriptor to @c /dev/uinput,
 * @param[out] uinput_dev The newly created libevdev device.
 *
 * @return 0 on success or a negative errno on failure. On failure, the value of
 * uinput_dev is unmodified.
 *
 * @see libevdev_uinput_destroy
 */
int libevdev_uinput_create_from_device(const struct libevdev *dev,
                                       int uinput_fd,
                                       struct libevdev_uinput **uinput_dev);
ikirill commented 9 years ago

Thank you for reporting these (the other bug too).

The issue is that parsing function call syntax is done in emacs-lisp, so it is a little bit "hacky". Given that libclang can already parse c++ perfectly, it is better to (eventually) dump the parsing code in emacs-lisp and rely on libclang entirely. I'll see if there's an easy fix, but if there isn't it will eventually be fixed by using libclang instead.

ackalker commented 9 years ago

Thanks for your quick reply. Perhaps you can get some ideas from one of the company backends, company-clang (built-in) or company-irony.

alexmurray commented 7 years ago

Or use semantic to do the parsing if it is available / enabled already?