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

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

[noah]

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

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.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-10-27 built on noah-M51AC
Repository revision: 0e4dd67aae8b10032317a29a6bd99d2d4a64c897
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Ubuntu 18.04.3 LTS

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
previous-line: Beginning of buffer

Configured using:
 'configure --prefix=/usr/local --with-modules --with-xwidgets'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 44989 6110)
 (symbols 48 6002 1)
 (strings 32 15444 1947)
 (string-bytes 1 504797)
 (vectors 16 10036)
 (vector-slots 8 129209 9586)
 (floats 8 20 24)
 (intervals 56 189 0)
 (buffers 1000 11))

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

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

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>>     (defun my-octave-bounds-of-object-at-point (&optional lim)

[...]

>> 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.

It's not clear how this new octave-bounds-of-object-at-point is supposed
to be used here, either?  Could you explain?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It's not clear how this new octave-bounds-of-object-at-point is supposed
> to be used here, either?  Could you explain?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If progress can be made,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no