:regexp to abbrev table

:regexp to abbrev table

[Leo]

Hello Stefan and all,

If I want abbrevs to contain symbol, word, or \ (desirable in TeX), how
to construct a :regexp to the abbrev table? (For example, in TikZ, \node
and node are both meaningful, so one would naturally want \n to expand
into \node and n to expand into node).

The abbrev itself should match \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\). Since
currently :regexp also needs to match part of the text before the
abbrev, how to prepend \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\) so that abbrevs
can be correctly found? Something similar to \\(\\Sw\\|\\S_\\|\\S\\\\)
but without adding the extra group.

Do you think using greedy looking-back in abbrev--before-point will make
creating the :regexp property easier?

Thanks,

Leo

Re: :regexp to abbrev table

[Stefan Monnier]

> If I want abbrevs to contain symbol, word, or \ (desirable in TeX), how
> to construct a :regexp to the abbrev table? (For example, in TikZ, \node
> and node are both meaningful, so one would naturally want \n to expand
> into \node and n to expand into node).

> The abbrev itself should match \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\). Since
> currently :regexp also needs to match part of the text before the
> abbrev, how to prepend \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\) so that abbrevs
> can be correctly found? Something similar to \\(\\Sw\\|\\S_\\|\\S\\\\)
> but without adding the extra group.

Adding an extra group is no problem, as long as you make it shy
(i.e. an \(?:..\) rather than \(..\) so that it doesn't get a group
number).  Remember that "The submatch 1 is treated
as the potential name of an abbrev" so the subgroup nb 1 can be preceded
by any text you like.

> Do you think using greedy looking-back in abbrev--before-point will make
> creating the :regexp property easier?

It often would, yes.   But it could also negatively affect performance.


        Stefan

Re: :regexp to abbrev table

[Leo]

On 2010-04-19 07:29 +0100, Stefan Monnier wrote:
>> The abbrev itself should match \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\). Since
>> currently :regexp also needs to match part of the text before the
>> abbrev, how to prepend \\(\\(\\sw\\|\\s_\\|\\s\\\\)+\\) so that abbrevs
>> can be correctly found? Something similar to \\(\\Sw\\|\\S_\\|\\S\\\\)
>> but without adding the extra group.
>
> Adding an extra group is no problem, as long as you make it shy
> (i.e. an \(?:..\) rather than \(..\) so that it doesn't get a group
> number).  Remember that "The submatch 1 is treated
> as the potential name of an abbrev" so the subgroup nb 1 can be preceded
> by any text you like.

I have been trying all afternoon to construct such a regexp. Asking also
on irc #emacs and emacs-help and I haven't received an answer yet.

Is it possible for you to provide an actual regexp to find abbrevs that
contains word, symbol or \?

>> Do you think using greedy looking-back in abbrev--before-point will make
>> creating the :regexp property easier?
>
> It often would, yes.   But it could also negatively affect performance.

I don't know the impact on performance. But since it is capped by
(line-beginning-position) will it matter that much? During the time I
enabled greedy looking-back, I haven't noticed any slow down.

Do you think it worthwhile to provide another property :syntax to allow
user to easily specify, for example, a value "w_\\" and find the abbrev
name correctly?

Leo

Re: :regexp to abbrev table

[Leo]

On 19 April 2010 19:56, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Is it possible for you to provide an actual regexp to find abbrevs that
>> contains word, symbol or \?
>
> I'd start with "\\(?:^\\|[^[:word:]\\]\\)\\([[:word:]\\]+\\)[ \t]*".
> For symbols, I recommend you list the chars you want in the above regexp
> rather than rely on the `symbol' char syntax.

Many thanks for this. I will bear this in mind when writing the abbrev
completion code. Since TAB can be configured to perform two roles:
indentation and completion through (setq tab-always-indent 'complete).
Completion in the middle of a 'word' often lead to undesirable change
of the text in buffer. For example: (emacs-lis|p-mode) where | is the
cursor. TAB will change the text to (emacs-lisp-p-mode). I often type
TAB to check whether current line is correctly indented and so this
completion is annoying, for lisp-mode I have redefined
lisp-completion-at-point to work around this problem.

The same situation applies to abbrevs and the :regexp doesn't make it
easy to find the 'end' boundary.

>>>> Do you think using greedy looking-back in abbrev--before-point will make
>>>> creating the :regexp property easier?
>>> It often would, yes.   But it could also negatively affect performance.
>> I don't know the impact on performance. But since it is capped by
>> (line-beginning-position) will it matter that much? During the time I
>> enabled greedy looking-back, I haven't noticed any slow down.
>
> Under normal circumstances, I don't expect serious performance
> problems, indeed.  But since the code might be executed very often even
> for users who will almost never use those abbrevs, we have to be careful
> so it works in more cases than the expected one.
> This said, I do not know if my performance worries are justified.
>
>
>        Stefan

Leo

Re: :regexp to abbrev table

[Stefan Monnier]

>>> Is it possible for you to provide an actual regexp to find abbrevs that
>>> contains word, symbol or \?
>> I'd start with "\\(?:^\\|[^[:word:]\\]\\)\\([[:word:]\\]+\\)[ \t]*".
>> For symbols, I recommend you list the chars you want in the above regexp
>> rather than rely on the `symbol' char syntax.
> Many thanks for this. I will bear this in mind when writing the abbrev
> completion code. Since TAB can be configured to perform two roles:
> indentation and completion through (setq tab-always-indent 'complete).
> Completion in the middle of a 'word' often lead to undesirable change
> of the text in buffer. For example: (emacs-lis|p-mode) where | is the
> cursor. TAB will change the text to (emacs-lisp-p-mode).

This is indeed a problem we need to fix: it should take the tail into
account, just as is done in the minibuffer.  Try the patch below.
Of course, it will not necessarily always solve the problem that "I just
wanted to reindent and it started to complete and annoyed me".

> The same situation applies to abbrevs and the :regexp doesn't make it
> easy to find the 'end' boundary.

I don't understand how it relates.


        Stefan


=== modified file 'lisp/emacs-lisp/lisp.el'
--- lisp/emacs-lisp/lisp.el	2010-01-13 08:35:10 +0000
+++ lisp/emacs-lisp/lisp.el	2010-04-20 15:20:36 +0000
@@ -631,12 +631,11 @@
 
 (defun lisp-completion-at-point (&optional predicate)
   ;; FIXME: the `end' could be after point?
-  (let* ((end (point))
+  (let* ((pos (point))
          (beg (with-syntax-table emacs-lisp-mode-syntax-table
                 (save-excursion
                   (backward-sexp 1)
-                  (while (= (char-syntax (following-char)) ?\')
-                    (forward-char 1))
+                  (skip-syntax-forward "'")
                   (point))))
          (predicate
           (or predicate
@@ -656,12 +655,21 @@
                       ;; Maybe a `let' varlist or something.
                       nil
                     ;; Else, we assume that a function name is expected.
-                    'fboundp))))))
+                    'fboundp)))))
+         (end
+          (unless (or (eq beg (point-max))
+                      (member (char-syntax (char-after beg)) '(?\( ?\))))
+            (save-excursion
+              (goto-char beg)
+              (forward-sexp 1)
+              (when (>= (point) pos)
+                (point))))))
+    (when end
     (list beg end obarray
           :predicate predicate
           :annotate-function
             (unless (eq predicate 'fboundp)
-              (lambda (str) (if (fboundp (intern-soft str)) " <f>"))))))
+              (lambda (str) (if (fboundp (intern-soft str)) " <f>")))))))
 
 ;; arch-tag: aa7fa8a4-2e6f-4e9b-9cd9-fef06340e67e
 ;;; lisp.el ends here

Re: :regexp to abbrev table

[Leo]

On 2010-04-20 16:22 +0100, Stefan Monnier wrote:
>> Many thanks for this. I will bear this in mind when writing the abbrev
>> completion code. Since TAB can be configured to perform two roles:
>> indentation and completion through (setq tab-always-indent 'complete).
>> Completion in the middle of a 'word' often lead to undesirable change
>> of the text in buffer. For example: (emacs-lis|p-mode) where | is the
>> cursor. TAB will change the text to (emacs-lisp-p-mode).
>
> This is indeed a problem we need to fix: it should take the tail into
> account, just as is done in the minibuffer.  Try the patch below.
> Of course, it will not necessarily always solve the problem that "I just
> wanted to reindent and it started to complete and annoyed me".

The code works fine except probably wrapping backward-sexp inside
ignore-errors for the case like this (|emacs-lisp-mode). Otherwise
it errs with:

forward-sexp: Scan error: "Containing expression ends prematurely", 228, 228

Will you consider applying the patch to trunk?

Leo

Re: :regexp to abbrev table

[Leo]

On 2010-04-20 17:32 +0100, Leo wrote:
> Scan error: "Containing expression ends prematurely", 228, 228
>
> Will you consider applying the patch to trunk?

Thank you for committing this to trunk.

As mentioned in previous post, (|emacs-lisp-mode) then hit TAB throws an
error. Is that intended?

Leo

Re: :regexp to abbrev table

[Stefan Monnier]

>> Scan error: "Containing expression ends prematurely", 228, 228
>> Will you consider applying the patch to trunk?
> Thank you for committing this to trunk.
> As mentioned in previous post, (|emacs-lisp-mode) then hit TAB throws an
> error. Is that intended?

I can't reproduce this problem.


        Stefan

Re: :regexp to abbrev table

[Leo]

On 2010-04-21 05:26 +0100, Stefan Monnier wrote:
>>> Scan error: "Containing expression ends prematurely", 228, 228
>>> Will you consider applying the patch to trunk?
>> Thank you for committing this to trunk.
>> As mentioned in previous post, (|emacs-lisp-mode) then hit TAB throws an
>> error. Is that intended?
>
> I can't reproduce this problem.

Is your TAB does completion as well? Otherwise M-TAB can trigger this
too. When the cursor is in that position, eval (backward-sexp 1) throws
this error which I can reproduce with 23.1.96.

>         Stefan

Leo

Re: :regexp to abbrev table

[Leo]

On 21 April 2010 15:15, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>>>> Scan error: "Containing expression ends prematurely", 228, 228
>>>>> Will you consider applying the patch to trunk?
>>>> Thank you for committing this to trunk.
>>>> As mentioned in previous post, (|emacs-lisp-mode) then hit TAB throws an
>>>> error. Is that intended?
>>> I can't reproduce this problem.
>> Is your TAB does completion as well? Otherwise M-TAB can trigger this
>> too. When the cursor is in that position, eval (backward-sexp 1) throws
>> this error which I can reproduce with 23.1.96.
>
> No, I really mean it: I can't reproduce it.  Please give us a recipe
> starting from "emacs -Q".

Assume the new completion code is preloaded.

1. Emacs -Q -nw
2. In the scratch buffer, type in the text (emacs-lisp-mode)
3. Move the cursor to be immediately after (
4. Press M-TAB

   Scan error: "Containing expression ends prematurely", 192, 192

>        Stefan

Leo

Re: :regexp to abbrev table

[Leo]

On 21 April 2010 19:00, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Assume the new completion code is preloaded.
>> 1. Emacs -Q -nw
>> 2. In the scratch buffer, type in the text (emacs-lisp-mode)
>> 3. Move the cursor to be immediately after (
>> 4. Press M-TAB
>
> Ah... so your "|" was the position of point, yes I see it now, thank you.
> It should be fixed now thanks to the patch below,

I should be more explicit. Thank you for fixing it. BTW, is the fixme
comment still relevant?

>> The same situation applies to abbrevs and the :regexp doesn't make it
>> easy to find the 'end' boundary.
> I don't understand how it relates.

I was wrong. It have resolved this issue.

>        Stefan

Leo

Re: :regexp to abbrev table

[Stefan Monnier]

> BTW, is the fixme comment still relevant?

Indeed, no,


        Stefan