Skip to content
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

Problem with doc on multi-line function call #2

Open
ackalker opened this issue Jan 6, 2015 · 4 comments
Open

Problem with doc on multi-line function call #2

ackalker opened this issue Jan 6, 2015 · 4 comments

Comments

@ackalker
Copy link

ackalker commented Jan 6, 2015

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
Copy link
Author

ackalker commented Jan 6, 2015

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
Copy link
Owner

ikirill commented Jan 6, 2015

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
Copy link
Author

ackalker commented Jan 7, 2015

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants