* :regexp to abbrev table @ 2010-04-16 10:06 Leo 2010-04-19 6:29 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-16 10:06 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-16 10:06 :regexp to abbrev table Leo @ 2010-04-19 6:29 ` Stefan Monnier 2010-04-19 18:26 ` Leo 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2010-04-19 6:29 UTC (permalink / raw) To: Leo; +Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-19 6:29 ` Stefan Monnier @ 2010-04-19 18:26 ` Leo [not found] ` <jwvljcj8ee1.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-19 18:26 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <jwvljcj8ee1.fsf-monnier+emacs@gnu.org>]
* Re: :regexp to abbrev table [not found] ` <jwvljcj8ee1.fsf-monnier+emacs@gnu.org> @ 2010-04-20 13:37 ` Leo 2010-04-20 15:22 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-20 13:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-20 13:37 ` Leo @ 2010-04-20 15:22 ` Stefan Monnier 2010-04-20 16:32 ` Leo 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2010-04-20 15:22 UTC (permalink / raw) To: Leo; +Cc: emacs-devel >>> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-20 15:22 ` Stefan Monnier @ 2010-04-20 16:32 ` Leo 2010-04-20 18:39 ` Leo 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-20 16:32 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-20 16:32 ` Leo @ 2010-04-20 18:39 ` Leo 2010-04-21 4:26 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-20 18:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-20 18:39 ` Leo @ 2010-04-21 4:26 ` Stefan Monnier 2010-04-21 6:37 ` Leo 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2010-04-21 4:26 UTC (permalink / raw) To: Leo; +Cc: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-21 4:26 ` Stefan Monnier @ 2010-04-21 6:37 ` Leo [not found] ` <jwv4oj46gfy.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-21 6:37 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <jwv4oj46gfy.fsf-monnier+emacs@gnu.org>]
* Re: :regexp to abbrev table [not found] ` <jwv4oj46gfy.fsf-monnier+emacs@gnu.org> @ 2010-04-21 15:09 ` Leo [not found] ` <jwvaasw4s7w.fsf-monnier+emacs@gnu.org> 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-21 15:09 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <jwvaasw4s7w.fsf-monnier+emacs@gnu.org>]
* Re: :regexp to abbrev table [not found] ` <jwvaasw4s7w.fsf-monnier+emacs@gnu.org> @ 2010-04-21 19:25 ` Leo 2010-04-23 3:23 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Leo @ 2010-04-21 19:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: :regexp to abbrev table 2010-04-21 19:25 ` Leo @ 2010-04-23 3:23 ` Stefan Monnier 0 siblings, 0 replies; 12+ messages in thread From: Stefan Monnier @ 2010-04-23 3:23 UTC (permalink / raw) To: Leo; +Cc: emacs-devel > BTW, is the fixme comment still relevant? Indeed, no, Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-04-23 3:23 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-16 10:06 :regexp to abbrev table Leo 2010-04-19 6:29 ` Stefan Monnier 2010-04-19 18:26 ` Leo [not found] ` <jwvljcj8ee1.fsf-monnier+emacs@gnu.org> 2010-04-20 13:37 ` Leo 2010-04-20 15:22 ` Stefan Monnier 2010-04-20 16:32 ` Leo 2010-04-20 18:39 ` Leo 2010-04-21 4:26 ` Stefan Monnier 2010-04-21 6:37 ` Leo [not found] ` <jwv4oj46gfy.fsf-monnier+emacs@gnu.org> 2010-04-21 15:09 ` Leo [not found] ` <jwvaasw4s7w.fsf-monnier+emacs@gnu.org> 2010-04-21 19:25 ` Leo 2010-04-23 3:23 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.