bug#37951: 27.0.50; octave completion-at-point for fieldnames

[Stefan Kangas]

noah <noah.v.peart@gmail.com> writes:

> This is relevant to octave.el (should I be sending to a different
> list or tagging it somehow?)

Yes, this is the correct list.

> The completion-at-point functions in both octave source buffers
> and inferior octave buffers don't complete for fieldnames of
> eg. structs. For example, it would be nice to get completion
> candidates after '.' in these cases
>
>     octave> s(1) = struct('field1', [], 'field2', [])
>     octave> s(2) = struct('field1', [], 'field2', [])
>     octave> s.         # case 1
>     octave> s(1).      # case 2
>     
> This is simply a matter of not capturing the correct bounds of
> objects at point in `octave-completion-at-point` and
> `inferior-octave-completion-at-point`.
>
> The octave function `completion_matches` already returns the correct
> completion candidates ("s.field1" "s.field2") when passed the full
> "s." or "s(1)." strings in the above example.
>
> The following modification to retrieve the bounds of the object
> at point seems to work in both source and inferior buffers.
>
>     (defun my-octave-bounds-of-object-at-point (&optional lim)
>       (let ((beg (save-excursion
>                    (skip-syntax-backward "w_" lim)
>                    ;; just this extra check
>                    (when (eq ?. (char-before))
>                      (forward-char -1)
>                      (and (eq ?\) (char-before)) ; struct(i).
>                           (ignore-errors (backward-sexp)))
>                      (skip-syntax-backward "w_" lim))
>                    (point)))
>             (end (point)))
>         (when (< beg end)                   ; extends region past point
>           (save-excursion
>             (skip-syntax-forward "w_")
>             (setq end (point))))
>         (when (> end beg)
>           (cons beg end))))
>
> However, being pretty new to octave, I'm not sure about all the cases
> where this completion would be applicable.

Could you send the above as a patch or a diff instead?  That would
increase the chances of us being able to integrate and use your
changes.  You should preferably send a patch against the latest
development sources available via git.

Thanks in advance.

Best regards,
Stefan Kangas