New completion mode

New completion mode

[Lars Magne Ingebrigtsen]

Has anybody written the completion mode I twittered about a few years
back?  That is, kinda like what Firefox does when you type in an URL?

I may be slightly feverish, but the thing might work thusly in Emacs:

You're on an address header:

  To:

and you type

  To: la

Emacs would then show you the possible completions, ranked in the
most-likely order.  (Likelihood might be based on number of times the
address has been used, and how recently it was used, and perhaps
other... things.)

How to display the list, though?  One possibility would be in the echo
area.  Just display the ten most highly ranked ones, and choose them
with, say, `M-n M-n RET' or the like.  Or pop up a small helper
buffer.  Or a frame?

Or has anybody written this already?  Does bbdb do this?  Perhaps I
should have a peek...

When does this list come back to life again?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Sam Steingold]

> * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 12:30:21 +0200]:
>
> Has anybody written the completion mode I twittered about a few years
> back?  That is, kinda like what Firefox does when you type in an URL?

M-x apropos RET mail-complete RET

(I am sure you know about it, I am just making sure that those who do
not will not be misled into thinking that Emacs has no mail completion
functionality at all).

> Or has anybody written this already?  Does bbdb do this?

bbdb-complete-name

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz)
http://pmw.org.il http://www.camera.org http://www.palestinefacts.org
http://www.openvotingconsortium.org http://www.memri.org
Which should be served first: the chicken salad or the egg salad?

Re: New completion mode

[Lars Magne Ingebrigtsen]

Sam Steingold <sds@podval.org> writes:

>> * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 12:30:21 +0200]:
>>
>> Has anybody written the completion mode I twittered about a few years
>> back?  That is, kinda like what Firefox does when you type in an URL?
>
> M-x apropos RET mail-complete RET

Hm.  I don't think mail-complete does what I described...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Sam Steingold]

> * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 17:52:09 +0200]:
>
> Sam Steingold <sds@podval.org> writes:
>
>>> * Lars Magne Ingebrigtsen <ynefv@tahf.bet> [2006-04-11 12:30:21 +0200]:
>>>
>>> Has anybody written the completion mode I twittered about a few years
>>> back?  That is, kinda like what Firefox does when you type in an URL?
>>
>> M-x apropos RET mail-complete RET
>
> Hm.  I don't think mail-complete does what I described...

no, it's not "electric" enough, but it conforms to the general emacs
approach of not interfering with an ardent typist.

I am sure one can electrify mail-complete to suite your wishes.

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 4 (Stentz)
http://www.iris.org.il http://ffii.org http://www.openvotingconsortium.org
http://www.savegushkatif.org http://www.honestreporting.com
(let ((a "(let ((a %c%s%c)) (format a 34 a 34))")) (format a 34 a 34))

Re: New completion mode

[Lars Magne Ingebrigtsen]

Sam Steingold <sds@podval.org> writes:

> I am sure one can electrify mail-complete to suite your wishes.

I kinda doubt it.

Ok; I'm starting to write ecomplete.el.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Ok; I'm starting to write ecomplete.el.

Is there a way to have text properties in the text shown in the echo
area?  (message "%s" text-with-properties) doesn't really seem to
work... 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Reiner Steib]

On Wed, Apr 12 2006, Lars Magne Ingebrigtsen wrote:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Ok; I'm starting to write ecomplete.el.

ECB or one of the packages used by it _might_ have such (or similar)
functions.  (I don't use ECB it myself.)

> Is there a way to have text properties in the text shown in the echo
> area?  (message "%s" text-with-properties) doesn't really seem to
> work... 

It should work, I think:

http://search.gmane.org/?query=message+function+with+propertized+string&group=gmane.emacs.help

Selecting (message (propertize "foobar toto" 'face 'highlight)) in
*scratch* saying M-x eval-region RET works for me.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: New completion mode

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> ECB or one of the packages used by it _might_ have such (or similar)
> functions.  (I don't use ECB it myself.)

I had a *very* quick look over the documentation, and I couldn't see
anything very promising in the auto-complete area.

> Selecting (message (propertize "foobar toto" 'face 'highlight)) in
> *scratch* saying M-x eval-region RET works for me.

Great; thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Lars Magne Ingebrigtsen]

Well, the current implementation has hit a small snag.  I had planned
on using `(current-message)' to find if the user was in the middle of
selecting a completion, but it looks like Emacs clears the echo area
before commands are called...

*sigh*

Back to the drawing board.
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Lars Magne Ingebrigtsen]

Ok; I've now reimplemented selection as a loop.  I must have forgotten
something basic, though, because I just can't seem to get anything
useful out of `read-event'.  That is, I want to check for `M-n', but I
don't know how to map `M-n' to or from the event code...
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Wolfram Fenske]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> You're on an address header:
>
>   To:
>
> and you type
>
>   To: la
>
> Emacs would then show you the possible completions, ranked in the
> most-likely order.  (Likelihood might be based on number of times the
> address has been used, and how recently it was used, and perhaps
> other... things.)
>
> How to display the list, though?  One possibility would be in the echo
> area.  Just display the ten most highly ranked ones, and choose them
> with, say, `M-n M-n RET' or the like.  Or pop up a small helper
> buffer.  Or a frame?
>
> Or has anybody written this already?  Does bbdb do this?  Perhaps I
> should have a peek...

Yes, bbdb sorta does this, you should have a look at it.  You type
some characters and when you press TAB, a *Completions* buffer is
shown on the bottom of the screen.  It's very similar to the
completion function of "find-file."  bbdb doesn't do any ranking,
though, as far as I can tell.

If you still want to implement this, I think a completions buffer is
less intrusive (better) than what Firefox does.  I always feel
Firefox's popup gets a little in the way of my typing, but I can't
tell exactly why.


Regards
Wolfram

-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: New completion mode

[Lars Magne Ingebrigtsen]

Wolfram Fenske <Wolfram.Fenske@Student.Uni-Magdeburg.DE> writes:

> Yes, bbdb sorta does this, you should have a look at it.

(What's the copyright status of bbdb?  I vaguely seem to recall that
it can't be included in Emacs...)

> If you still want to implement this, I think a completions buffer is
> less intrusive (better) than what Firefox does.  I always feel
> Firefox's popup gets a little in the way of my typing, but I can't
> tell exactly why.

I've never quite liked the completions buffer.  :-)  It seems to break
to flow when typing, while the Firefox approach seems so natural. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Wolfram Fenske]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (What's the copyright status of bbdb?  I vaguely seem to recall that
> it can't be included in Emacs...)

I don't know about this stuff.

>> If you still want to implement this, I think a completions buffer is
>> less intrusive (better) than what Firefox does.  I always feel
>> Firefox's popup gets a little in the way of my typing, but I can't
>> tell exactly why.
>
> I've never quite liked the completions buffer.  :-)  It seems to break
> to flow when typing, while the Firefox approach seems so natural. 

OK, what is a more natural about the Firefox approach is that you
don't have to type `C-x o' to be able to select anything.  But one
might argue that this isn't unnatural for somebody familiar with
Emacs.  If you don't want to use any of the suggestions, both
approaches are equally natural: you can simply keep typing.

Preferences aside, IMO, the *Completions* buffer is still better
because it's more consistent with the rest of Emacs.  And as you know,
consistency goes a long way in UI design.  It's even quite similar to
the auto-completion features in popular shells, e. g. bash.

One thing I don't like about the Firefox approach is that a window
pops up without my having asked for it.  I find that distracting.  In
bbdb, I press TAB to activate auto-completion.  Admittedly, having to
do this makes the feature less obvious than Firefox's popup, but since
I use the shell a lot, this is my normal reflex, anyway.  If what I've
typed so far is unambiguous, auto-completion fills in the rest of the
email address for me.  If not, I get a completions buffer.  This
behavior is very similar to the way auto-completion works in bash or
when visiting files in Emacs.  Again, consistency.

Anyway, just my two cents.


Greetings
Wolfram
-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: New completion mode

[Jochen Küpper]

Lars Magne Ingebrigtsen <larsi-smP1P7uqpqc@public.gmane.org> writes:

> Wolfram Fenske <Wolfram.Fenske-SVAqIv1tV6AWujOHlbWvjPJ10hmV2uTd@public.gmane.org> writes:
>
>> Yes, bbdb sorta does this, you should have a look at it.
>
> (What's the copyright status of bbdb?  I vaguely seem to recall that
> it can't be included in Emacs...)

Well, it's GPL, but I am not sure jwz has signed FSF papers...
,----
| ;;; This file is the core of the Insidious Big Brother Database (aka BBDB),
| ;;; copyright (c) 1991, 1992, 1993, 1994 Jamie Zawinski <jwz-VsqqI1RANlFWk0Htik3J/w@public.gmane.org>.
| ;;; See the file bbdb.texinfo for documentation.
| ;;;
| ;;; The Insidious Big Brother Database is free software; you can redistribute
| ;;; it and/or modify it under the terms of the GNU General Public License as
| ;;; published by the Free Software Foundation; either version 2, or (at your
| ;;; option) any later version.
`----

Wolfram Fenske <Wolfram.Fenske-SVAqIv1tV6AWujOHlbWvjPJ10hmV2uTd@public.gmane.org> writes:

> Preferences aside, IMO, the *Completions* buffer is still better
> because it's more consistent with the rest of Emacs.  And as you know,
> consistency goes a long way in UI design.  It's even quite similar to
> the auto-completion features in popular shells, e. g. bash.

I would totally agree here.

Although I typically seem to "know" how far I have to type to have TAB
(running bbdb-complete-name) complete the full entry directly...

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

Re: New completion mode

[Lars Magne Ingebrigtsen]

Jochen Küpper writes:

> Although I typically seem to "know" how far I have to type to have TAB
> (running bbdb-complete-name) complete the full entry directly...

It's the "knowing" I don't like.  If I wanted to know stuff, I
wouldn't use a computer.  :-)

Anyway,

(setq message-mail-alias-type 'ecomplete)

and be either shocked or something else.  It works by collecting
addresses automatically, and after it has some addresses to show you,
it'll show you when you're typing in the To or Cc headers.  Choose
with `M-n'/`RET'.

The implementation may not be completely perfect yet.  Ahem.  :-)
Especially since I was quite naughty with the `after-change-functions'
variable.  This might blow up at any moment.  Should change that...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Use of ecomplete.el in message.el (was: New completion mode)

[Reiner Steib]

On Fri, Apr 14 2006, Lars Magne Ingebrigtsen wrote:

> Anyway,
> (setq message-mail-alias-type 'ecomplete)
> and be either shocked or something else.  It works by collecting
> addresses automatically, and after it has some addresses to show you,
> it'll show you when you're typing in the To or Cc headers.  Choose
> with `M-n'/`RET'.

I didn't try it yet (I'm quite happy with BBDB).  Just some remarks:

- In `message-put-addresses-in-ecomplete' you should use
  `gnus-replace-in-string' instead of `replace-regexp-in-string' for
  compatibility with XEmacs.

- Wouldn't (autoload 'ecomplete-setup "ecomplete") be sufficient
  instead of (require 'ecomplete)?

- Maybe it would be better to use a file under ~/.emacs.d/ or
  ~/.xemacs/ for `ecomplete-database-file'.  See e.g. `savehist-file'
  (recent addition to Emacs).

- (defgroup ecomplete nil
    "Suppression of duplicate articles."
    :group 'mail)

  Copy and paste error?

- You might want to set `show-trailing-whitespace' to t in
  emacs-lisp-mode and change-log-mode or use `M-x
  delete-trailing-whitespace RET' from time to time .  ;-)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Use of ecomplete.el in message.el

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> - In `message-put-addresses-in-ecomplete' you should use
>   `gnus-replace-in-string' instead of `replace-regexp-in-string' for
>   compatibility with XEmacs.

Fixed.

> - Wouldn't (autoload 'ecomplete-setup "ecomplete") be sufficient
>   instead of (require 'ecomplete)?

Then I'd get compilation warnings on all the other ecomplete
functions, wouldn't I?

> - Maybe it would be better to use a file under ~/.emacs.d/ or
>   ~/.xemacs/ for `ecomplete-database-file'.  See e.g. `savehist-file'
>   (recent addition to Emacs).

Hm.  Couldn't find `savehist-file'...

> - (defgroup ecomplete nil
>     "Suppression of duplicate articles."
>     :group 'mail)
>
>   Copy and paste error?

Yup; fixed.

> - You might want to set `show-trailing-whitespace' to t in
>   emacs-lisp-mode and change-log-mode or use `M-x
>   delete-trailing-whitespace RET' from time to time .  ;-)

Oh, have we changed to deleting trailing whitespace in all the files? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Use of ecomplete.el in message.el

[Reiner Steib]

On Sun, Apr 16 2006, Lars Magne Ingebrigtsen wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> - Wouldn't (autoload 'ecomplete-setup "ecomplete") be sufficient
>>   instead of (require 'ecomplete)?
>
> Then I'd get compilation warnings on all the other ecomplete
> functions, wouldn't I?

Hm, yes.  Maybe I should try my suggestions.  ;-)

>> - Maybe it would be better to use a file under ~/.emacs.d/ or
>>   ~/.xemacs/ for `ecomplete-database-file'.  See e.g. `savehist-file'
>>   (recent addition to Emacs).
>
> Hm.  Couldn't find `savehist-file'...

Try after `M-x savehist-mode RET' or (require 'savehist).  A very nice
feature, btw.

>> - You might want to set `show-trailing-whitespace' to t in
>>   emacs-lisp-mode and change-log-mode or use `M-x
>>   delete-trailing-whitespace RET' from time to time .  ;-)
>
> Oh, have we changed to deleting trailing whitespace in all the files? 

I don't know if it has changed; I think it's an Emacs policy.  IIRC
some changes merged back from Emacs CVS removed the trailing
whitespace in some *.el files.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Use of ecomplete.el in message.el

[Lars Magne Ingebrigtsen]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Try after `M-x savehist-mode RET' or (require 'savehist).  A very nice
> feature, btw.

Oo.

(defcustom savehist-file
  (cond
   ;; Backward compatibility with previous versions of savehist.
   ((file-exists-p "~/.emacs-history") "~/.emacs-history")
   ((and (not (featurep 'xemacs)) (file-directory-p "~/.emacs.d/"))
    "~/.emacs.d/history")
   ((and (featurep 'xemacs) (file-directory-p "~/.xemacs/"))
    "~/.xemacs/history")
   ;; For users without `~/.emacs.d/' or `~/.xemacs/'.
   (t "~/.emacs-history"))

Has anybody made a `setup-file-name' function or the like that gets
all this right?

> I don't know if it has changed; I think it's an Emacs policy.  IIRC
> some changes merged back from Emacs CVS removed the trailing
> whitespace in some *.el files.

Ok.  Perhaps Gnus maintainers should have whitespace deletion on by
default in .el files.  Anybody have the correct incantation?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Use of ecomplete.el in message.el

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

* Reiner Steib <reinersteib+gmane@imap.cc> writes:

  > On Fri, Apr 14 2006, Lars Magne Ingebrigtsen wrote:
  >> (setq message-mail-alias-type 'ecomplete)

  > I didn't try it yet (I'm quite happy with BBDB).  Just some remarks:

I tried it last night with SXEmacs.  It didn't get to the point of
"collecting" any addresses (I didn't look too closely to see when that
happens... during reading or composing or both).  I tried composing an
email and noticed "No ecomplete matches" messages for every char I
typed in To header.  So I figured it was at least trying to do
something. 

Then I hit C-c C-c...

SXEmacs immediately became unusable.  It was locked up tighter than a
fish's... ahem.  C-g was no help.  I had to manually kill(1) it.

I'll try in XEmacs (although it shouldn't make a difference) and
report back.

  > - In `message-put-addresses-in-ecomplete' you should use
  >   `gnus-replace-in-string' instead of `replace-regexp-in-string' for
  >   compatibility with XEmacs.

Only needed for XEmacs 21.4.  XEmacs 21.5 and SXEmacs has
`replace-regexp-in-string'. 

  > - Maybe it would be better to use a file under ~/.emacs.d/ or
  >   ~/.xemacs/ for `ecomplete-database-file'.  See e.g. `savehist-file'
  >   (recent addition to Emacs).

For (S)XEmacs, I'd suggest...

  (expand-file-name ".ecompleterc" user-init-directory)


-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 257 bytes --]

Re: Use of ecomplete.el in message.el

[Lars Magne Ingebrigtsen]

Steve Youngs <steve@sxemacs.org> writes:

> SXEmacs immediately became unusable.  It was locked up tighter than a
> fish's... ahem.  C-g was no help.  I had to manually kill(1) it.

Wow.  Did strace say anything interesting?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jochen Küpper writes:
>
>> Although I typically seem to "know" how far I have to type to have TAB
>> (running bbdb-complete-name) complete the full entry directly...
>
> It's the "knowing" I don't like.  If I wanted to know stuff, I
> wouldn't use a computer.  :-)

Hear, hear.

> Anyway,
>
> (setq message-mail-alias-type 'ecomplete)
>
> and be either shocked or something else.

I like it.

> It works by collecting addresses automatically, and after it has
> some addresses to show you, it'll show you when you're typing in the
> To or Cc headers.  Choose with `M-n'/`RET'.

Wishlist: import all bbdb addresses automatically?  Below is the
format of my ~/.bbdb.  I have no idea why the many parenthesis, and
how older file-version formats look like.

;; -*-coding: iso-2022-7bit;-*-
;;; file-version: 6
;;; user-fields: (pgg-encrypt)
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
["Lars Magne" "Ingebrigtsen" nil nil nil nil ("larsi@gnus.org" "bugs@gnus.org") ((creation-date . "2004-11-29") (timestamp . "2006-04-18")) nil]
...
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)

Re: New completion mode

[Reiner Steib]

On Tue, Apr 18 2006, Simon Josefsson wrote:

> Wishlist: import all bbdb addresses automatically?  Below is the
> format of my ~/.bbdb.  I have no idea why the many parenthesis, and
> how older file-version formats look like.

I don't have these parenthesis in my.bbdb file:

;;; file-version: 6
;;; user-fields: (birthday www category expire gnokii)

["Lars Magne" "Ingebrigtsen" ("Lars M. Ingebrigtsen" "Lars Ingebrigtsen") nil nil nil ("larsi@gnus.org" "bugs@gnus.org" "lmi@gnus.org") ((creation-date . "2003-04-30") (timestamp . "2005-12-18")) nil]


But instead of parsing the .bbdb file on your own, you should better
use BBDB functions, I think.  This expression returns a list of all
addresses:

(let ((records (bbdb-records))
      nets)
  (dolist (i records)
    (dolist (n (bbdb-record-net i))
      (push n nets)))
  nets)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: New completion mode

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Tue, Apr 18 2006, Simon Josefsson wrote:
>
>> Wishlist: import all bbdb addresses automatically?  Below is the
>> format of my ~/.bbdb.  I have no idea why the many parenthesis, and
>> how older file-version formats look like.
>
> I don't have these parenthesis in my.bbdb file:
>
> ;;; file-version: 6
> ;;; user-fields: (birthday www category expire gnokii)
>
> ["Lars Magne" "Ingebrigtsen" ("Lars M. Ingebrigtsen" "Lars Ingebrigtsen") nil nil nil ("larsi@gnus.org" "bugs@gnus.org" "lmi@gnus.org") ((creation-date . "2003-04-30") (timestamp . "2005-12-18")) nil]
>
>
> But instead of parsing the .bbdb file on your own, you should better
> use BBDB functions, I think.  This expression returns a list of all
> addresses:
>
> (let ((records (bbdb-records))
>       nets)
>   (dolist (i records)
>     (dolist (n (bbdb-record-net i))
>       (push n nets)))
>   nets)

This assume the user still has bbdb installed... which might be good
enough.  If (require 'bbdb) fails, though, and ~/.bbdb exists, I
wonder whether it maybe should read it anyway.

On second thought, it may be simpler to not do anything automatically,
but simply provide a bbdb->ecomplete synching as a separate function,
possibly even in a separate file (to avoid polluting ecomplete.el with
bbdb stuff).

I like how ecomplete seem to get along nicely with bbdb.  There's no
reason for them to compete, they can complement each other.  Although
eventually, I would like Gnus to have bbdb's functionality built-in.
Or even a fraction of it, I only use auto-completing from it.  It is
quite annoying to have to install bbdb separately.

Re: New completion mode

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> On second thought, it may be simpler to not do anything automatically,
> but simply provide a bbdb->ecomplete synching as a separate function,
> possibly even in a separate file (to avoid polluting ecomplete.el with
> bbdb stuff).

I'm wondering whether that's necessary.  ecomplete builds up its store
of addresses pretty quickly, so after having it switched on a while
(with or without bbdb switched on at the same time), you'll get the
desired effect...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> On second thought, it may be simpler to not do anything automatically,
>> but simply provide a bbdb->ecomplete synching as a separate function,
>> possibly even in a separate file (to avoid polluting ecomplete.el with
>> bbdb stuff).
>
> I'm wondering whether that's necessary.  ecomplete builds up its store
> of addresses pretty quickly, so after having it switched on a while
> (with or without bbdb switched on at the same time), you'll get the
> desired effect...

Is it possible to manually add some e-mail addresses?  For example,
I've replied to several of your e-mails, but you use M-F-T, so I still
doesn't have you in the ecomplete database...  Perhaps a command to
digest an article for addresses to snarf, display them all in the
minibuffer, and have a key binding (0..9a..z) to pick one of them or !
for all of them.  Or something.

Re: New completion mode

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Is it possible to manually add some e-mail addresses?  For example,
> I've replied to several of your e-mails, but you use M-F-T, so I still
> doesn't have you in the ecomplete database...  Perhaps a command to
> digest an article for addresses to snarf, display them all in the
> minibuffer, and have a key binding (0..9a..z) to pick one of them or !
> for all of them.  Or something.

It's possible, but, on the other hand, I don't think Firefox allows
such a thing with the URL history.  I think for stuff like this that
simplicity has a certain charm.

(Ahem.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> I've never quite liked the completions buffer.  :-)  It seems to break
> to flow when typing, while the Firefox approach seems so natural. 

The "dynamically update list of completions on each keystroke" behavior
of firefox is great (though maybe not practical for emacs because of
speed issues).

The "fill in the rest of your input without being asked" behavior of
firefox sucks.  I hate it... it constantly gets in the way when I don't
_want_ to complete.  Do not do this (it makes even less sense in Emacs
than in firefox, as Emacs doesn't default to automatically deleting the
selection).

Of course when implementing an Emacs extension, it's better to err on
the side of being consistent with the rest of Emacs.

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: New completion mode

[Lars Magne Ingebrigtsen]

Miles Bader <miles@gnu.org> writes:

> The "dynamically update list of completions on each keystroke" behavior
> of firefox is great (though maybe not practical for emacs because of
> speed issues).

I've been using my new code a couple of days now, and it actually
seems to be workable.  I'm not sure how well it scales, though -- and
I have to implement item expiry to make sure the list doesn't grow
indefinitely. 

> The "fill in the rest of your input without being asked" behavior of
> firefox sucks.  I hate it... it constantly gets in the way when I don't
> _want_ to complete.  Do not do this (it makes even less sense in Emacs
> than in firefox, as Emacs doesn't default to automatically deleting the
> selection).

I'm only aiming for the completion that Firefox does in the URL input
area.  Auto-complete like what Firefox does in password boxes and the
like isn't part of this...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Wolfram Fenske]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Miles Bader <miles@gnu.org> writes:
>
> [...] 
>
>> The "fill in the rest of your input without being asked" behavior
>> of firefox sucks.  I hate it... it constantly gets in the way when
>> I don't _want_ to complete.  Do not do this [...]

I couldn't agree more.

> I'm only aiming for the completion that Firefox does in the URL input
> area.  Auto-complete like what Firefox does in password boxes and the
> like isn't part of this...

I find it annoying there, too.  I'm with Miles here: IMO, "completion,
but only when you ask for it" is a better approach.


Wolfram

-- 
A: Yes.
>Q: Are you sure?
>>A: Because it reverses the logical flow of conversation.
>>>Q: Why is top posting frowned upon?

Re: New completion mode

[Katsumi Yamaoka]

Hi,

I began to use ecomplete.el.  Thanks Lars.  That's excellent!
However, I noticed some problems with it.  Here they are:

1.
The regexp used in `message-put-addresses-in-ecomplete' causes
an infloop in XEmacs.  The test case is:

   (gnus-replace-in-string "yamaoka@jpl.org" "^ +\\| *$" "")

It might be due to an XEmacs bug.  Though it seems to be solved
by replacing the regexp with "^ +\\| +$".

2.
The completions list appears only when a user invokes the
`self-insert-command' command.  Especially in Japan, people use
various tools in order to write Japanese text.  Some tools
replace `self-insert-command' with the other command, e.g.,
`egg-self-insert-char', in many keys, and it is used even when
writing ASCII text.  So, we need to make changes in message.el
like the following:

(defcustom message-self-insert-commands '(self-insert-command)
  "List of `self-insert-command's used to trigger ecomplete.
When one of those commands is invoked to enter a character in To or Cc
header, ecomplete will suggest the candidates of recipients (see also
`message-mail-alias-type').  If you use some tool to enter non-ASCII
text and it replaces `self-insert-command' with the other command, e.g.
`egg-self-insert-char', you may want to add it to this list."
  :group 'message-various
  :type '(repeat function))

(defun message-strip-forbidden-properties (begin end &optional old-length)
  "docstring"
  (when (and (eq message-mail-alias-type 'ecomplete)
	     (memq this-command message-self-insert-commands))
    (message-display-abbrev))
[...]

3.
Ecomplete doesn't specify the coding system of the rc file.
Because of this, Emacs asks me a coding system used to save the
rc file whenever I send a mail ever since names which contain
Japanese text and Latin text were registered in the rc file.  To
make matters worse, such contents will be corrupted when XEmacs
saves them to the rc file since XEmacs doesn't have the facility
to determine the proper coding system.  In addition, XEmacs-Mule
will be unable to find a proper coding system to decode the
contents when reading the rc file, either.  I actually have
verified that both happen.

Therefore, I make a proposal to add a variable like
`ecomplete-database-file-coding-system'.  I think the best
choice for the default value is `iso-2022-7bit' which all
Emacsen (with Mule) support.  Putting the coding cookie to the
rc file would also be good.  It enables people to manually edit
the rc file safely and informs non-Mule XEmacs whether the
contents can be used and modified.

4.
Mail-abbrevs is still useful.  So, I use

(add-hook 'message-setup-hook (if (featurep 'xemacs)
				  'mail-aliases-setup
				'mail-abbrevs-setup))

even if I set `message-mail-alias-type' to `ecomplete'.  How
about making this option a list?

Regards,

Re: New completion mode

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

* Katsumi Yamaoka <yamaoka@jpl.org> writes:

  > I began to use ecomplete.el.  Thanks Lars.  That's excellent!
  > However, I noticed some problems with it.  Here they are:

  > 1.
  > The regexp used in `message-put-addresses-in-ecomplete' causes
  > an infloop in XEmacs.  The test case is:

  >    (gnus-replace-in-string "yamaoka@jpl.org" "^ +\\| *$" "")

  > It might be due to an XEmacs bug.  Though it seems to be solved
  > by replacing the regexp with "^ +\\| +$".

This fixed the problem I was seeing in SXEmacs too.

And I finally got around to trying with XEmacs.  Not good.  Hit `m' to
compose a message and got...

Debugger entered--Lisp error: (invalid-read-syntax "Integer constant overflow in reader" "1145532640" 10)
  read(#<buffer " *temp*">)
  ecomplete-setup()
  message-mode()
  message-pop-to-buffer("*mail*")
  message-mail()
  gnus-summary-mail-other-window(nil)
  call-interactively(gnus-summary-mail-other-window)

Contents of my ~/.ecompleterc...

((mail
("steve@bastard.youngs.au.com" 1 1145532640 "Steve Youngs <steve@bastard.youngs.au.com>")
("steve@youngs.au.com" 1 1145532640 "Steve Youngs <steve@youngs.au.com>")
)
)



-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 257 bytes --]

gnus-replace-in-string: Avoid inf-loop in XEmacs (was: New completion mode)

[Reiner Steib]

On Mon, Apr 17 2006, Steve Youngs wrote:

[ from <news:microsoft-free.87y7y5uk1k.fsf@youngs.au.com> ]

> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
[...]
>   > - In `message-put-addresses-in-ecomplete' you should use
>   >   `gnus-replace-in-string' instead of `replace-regexp-in-string' for
>   >   compatibility with XEmacs.
>
> Only needed for XEmacs 21.4.  XEmacs 21.5 and SXEmacs has
> `replace-regexp-in-string'. 

Is it just a wrapper around `replace-in-string' or is it Emacs
implementation of `replace-regexp-in-string'?  Hm...

,----
| ELISP> emacs-version
| "21.5  (beta21) \"corn\" (+CVS-20050720) XEmacs Lucid"
| ELISP> (replace-regexp-in-string "/*$" "/" "foo")
| "foo/"
| ELISP> (replace-in-string "foo" "/*$" "/")
| *** Eval error ***  Quit during evaluation   (inf-loop -> C-g)
`----

We should change `gnus-replace-in-string' as follows, I think:

--8<---------------cut here---------------start------------->8---
--- gnus-util.el	20 Apr 2006 12:10:00 +0200	6.104.2.24
+++ gnus-util.el	20 Apr 2006 14:52:55 +0200	
@@ -61,8 +61,6 @@
 
 (eval-and-compile
   (cond
-   ((fboundp 'replace-in-string)
-    (defalias 'gnus-replace-in-string 'replace-in-string))
    ((fboundp 'replace-regexp-in-string)
     (defun gnus-replace-in-string (string regexp newtext &optional literal)
       "Replace all matches for REGEXP with NEWTEXT in STRING.
@@ -71,6 +69,8 @@
 
 This is a compatibility function for different Emacsen."
       (replace-regexp-in-string regexp newtext string nil literal)))
+   ((fboundp 'replace-in-string)
+    (defalias 'gnus-replace-in-string 'replace-in-string))
    (t
     (defun gnus-replace-in-string (string regexp newtext &optional literal)
       "Replace all matches for REGEXP with NEWTEXT in STRING.
--8<---------------cut here---------------end--------------->8---

On Thu, Apr 20 2006, Steve Youngs wrote:

> * Katsumi Yamaoka <yamaoka@jpl.org> writes:
[...]
>   > The regexp used in `message-put-addresses-in-ecomplete' causes
>   > an infloop in XEmacs.  The test case is:
>
>   >    (gnus-replace-in-string "yamaoka@jpl.org" "^ +\\| *$" "")
>
>   > It might be due to an XEmacs bug.

It's a bug in XEmacs, see
<http://thread.gmane.org/gmane.emacs.xemacs.beta/16592/focus=16603>.

>   > Though it seems to be solved by replacing the regexp with "^
>   > +\\| +$".
>
> This fixed the problem I was seeing in SXEmacs too.

Does shifting down "((fboundp 'replace-in-string) ...)" solve this
problem too?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnus-replace-in-string: Avoid inf-loop in XEmacs

[Michael Olson]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Is it just a wrapper around `replace-in-string' or is it Emacs
> implementation of `replace-regexp-in-string'?  Hm...

Whatever it is, it doesn't seem to work properly.

After a bug report from an XEmacs user, I now use the following
function to provide this functionality for Emacs Muse.

(defun muse-replace-regexp-in-string (regexp replacement text &optional fixedcase literal)
  "Replace REGEXP with REPLACEMENT in TEXT.
If fourth arg FIXEDCASE is non-nil, do not alter case of replacement text.
If fifth arg LITERAL is non-nil, insert REPLACEMENT literally."
  (cond
   ((fboundp 'replace-in-string)
    (replace-in-string text regexp replacement literal))
   ((fboundp 'replace-regexp-in-string)
    (replace-regexp-in-string regexp replacement text fixedcase literal))
   (t (let ((repl-len (length replacement))
            start)
        (while (setq start (string-match regexp text start))
          (setq start (+ start repl-len)
                text (replace-match replacement fixedcase literal text))))
      text)))

This prefers `replace-in-string' to `replace-regexp-in-string'.

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Muse, Planner, ERC, EMMS
  /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Jabber: mwolson_at_hcoop.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: gnus-replace-in-string: Avoid inf-loop in XEmacs

[Reiner Steib]

On Thu, Apr 20 2006, Michael Olson wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>> Is it just a wrapper around `replace-in-string' or is it Emacs
>> implementation of `replace-regexp-in-string'?  Hm...
>
> Whatever it is, it doesn't seem to work properly.

Do you have a simple test case?

> After a bug report from an XEmacs user, I now use the following
> function to provide this functionality for Emacs Muse.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: gnus-replace-in-string: Avoid inf-loop in XEmacs

[Michael Olson]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Thu, Apr 20 2006, Michael Olson wrote:
>
>> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>
>>> Is it just a wrapper around `replace-in-string' or is it Emacs
>>> implementation of `replace-regexp-in-string'?  Hm...
>>
>> Whatever it is, it doesn't seem to work properly.
>
> Do you have a simple test case?

The report is filed here:
http://article.gmane.org/gmane.emacs.wiki.general/5429

-- 
Michael Olson -- FSF Associate Member #652 -- http://www.mwolson.org/
Interests: Emacs Lisp, text markup, protocols -- Muse, Planner, ERC, EMMS
  /` |\ | | | IRC: mwolson on freenode.net: #hcoop, #muse, #PurdueLUG
 |_] | \| |_| Jabber: mwolson_at_hcoop.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: gnus-replace-in-string: Avoid inf-loop in XEmacs

[Steve Youngs]

[-- Attachment #1.1: Type: text/plain, Size: 707 bytes --]

* Reiner Steib <reinersteib+gmane@imap.cc> writes:

  > On Mon, Apr 17 2006, Steve Youngs wrote:
  > [ from <news:microsoft-free.87y7y5uk1k.fsf@youngs.au.com> ]

  >> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
  > [...]
  >> > - In `message-put-addresses-in-ecomplete' you should use
  >> >   `gnus-replace-in-string' instead of `replace-regexp-in-string' for
  >> >   compatibility with XEmacs.
  >> 
  >> Only needed for XEmacs 21.4.  XEmacs 21.5 and SXEmacs has
  >> `replace-regexp-in-string'. 

  > Is it just a wrapper around `replace-in-string' or is it Emacs
  > implementation of `replace-regexp-in-string'?  Hm...

This is from SXEmacs (which I ripped from XE 21.5)...


[-- Attachment #1.2: Type: application/emacs-lisp, Size: 2598 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 988 bytes --]


  > We should change `gnus-replace-in-string' as follows, I think:
  > --- gnus-util.el	20 Apr 2006 12:10:00 +0200	6.104.2.24
  > +++ gnus-util.el	20 Apr 2006 14:52:55 +0200	

I wondered why this wouldn't apply for me, until I realised it was a
much older version of gnus-util.el that I had.  Is it from the v5-10
branch?  My copy (from CVS HEAD) is version 7.something.

  > On Thu, Apr 20 2006, Steve Youngs wrote:

  >> * Katsumi Yamaoka <yamaoka@jpl.org> writes:
  >> > Though it seems to be solved by replacing the regexp with "^
  >> > +\\| +$".
  >> 
  >> This fixed the problem I was seeing in SXEmacs too.

  > Does shifting down "((fboundp 'replace-in-string) ...)" solve this
  > problem too?

Yes.

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 257 bytes --]

Re: gnus-replace-in-string: Avoid inf-loop in XEmacs

[Reiner Steib]

On Thu, Apr 20 2006, Steve Youngs wrote:

> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
>   > Is it just a wrapper around `replace-in-string' or is it Emacs
>   > implementation of `replace-regexp-in-string'?  Hm...
>
> This is from SXEmacs (which I ripped from XE 21.5)...
>
>
> (defun replace-regexp-in-string (regexp rep string &optional
> 					fixedcase literal subexp start)
>   "Replace all matches for REGEXP with REP in STRING.

The code is the same as in current Emacs CVS.  Some corrections in the
doc string and comments have been made in the meantime.

[...]
>   > We should change `gnus-replace-in-string' as follows, I think:
>   > --- gnus-util.el	20 Apr 2006 12:10:00 +0200	6.104.2.24
>   > +++ gnus-util.el	20 Apr 2006 14:52:55 +0200	
>
> I wondered why this wouldn't apply for me, until I realised it was a
> much older version of gnus-util.el that I had.  Is it from the v5-10
> branch?

Yes, 6.104.2.24 is the v5-10 branch.

>   > Does shifting down "((fboundp 'replace-in-string) ...)" solve this
>   > problem too?
>
> Yes.

I've committed the change (v5-10 and trunk).  Feel free to adjust the
version info on SXEmacs when necessary:

   ;; Prefer `replace-regexp-in-string' (present in Emacs, XEmacs 21.5,
   ;; SXEmacs 22.1.4) over `replace-in-string'.  The later leads to inf-loops
   ;; on empty matches:
   ;;   (replace-in-string "foo" "/*$" "/")
   ;;   (replace-in-string "xe" "\\(x\\)?" "")

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: New completion mode

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

* Steve Youngs <steve@sxemacs.org> writes:

  > And I finally got around to trying with XEmacs.  Not good.  Hit `m' to
  > compose a message and got...

  > Debugger entered--Lisp error: (invalid-read-syntax "Integer constant overflow in reader" "1145532640" 10)
  >   read(#<buffer " *temp*">)
  >   ecomplete-setup()
  >   message-mode()
  >   message-pop-to-buffer("*mail*")
  >   message-mail()
  >   gnus-summary-mail-other-window(nil)
  >   call-interactively(gnus-summary-mail-other-window)

This seems to be "bignum"[1] related.  I just tried in a SXEmacs that
didn't have bignum.  I got a similar warning, but SXEmacs kept on
going.

So this is most likely a SXEmacs thing, but possibly a problem for
bignum enabled XEmacs 21.5 too.


Footnotes: 
[1]  In SXEmacs it is called "Enhanced Number Types"

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                 I am Dyslexic of Borg.                   | 
|    Fusistance is retile. Your arse will be laminated.    |
|------------------------------------<steve@sxemacs.org>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 257 bytes --]

Re: New completion mode

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The regexp used in `message-put-addresses-in-ecomplete' causes
> an infloop in XEmacs.  The test case is:
>
>    (gnus-replace-in-string "yamaoka@jpl.org" "^ +\\| *$" "")
>
> It might be due to an XEmacs bug.  Though it seems to be solved
> by replacing the regexp with "^ +\\| +$".

Ok; done.

> The completions list appears only when a user invokes the
> `self-insert-command' command.  Especially in Japan, people use
> various tools in order to write Japanese text.  Some tools
> replace `self-insert-command' with the other command, e.g.,
> `egg-self-insert-char', in many keys, and it is used even when
> writing ASCII text.  So, we need to make changes in message.el
> like the following:
>
> (defcustom message-self-insert-commands '(self-insert-command)

Yup.  I wonder whether there's a simpler solution to make this work
automatically.  The point of the check for `self-insert-command' was
just to avoid having the code trigger on totally automatic header
setup stuff.  (It would flash "No ecomplete matches" while generating
the header.)

But I don't see any obvious way to fix this, so I've installed your
change.

> Therefore, I make a proposal to add a variable like
> `ecomplete-database-file-coding-system'.  I think the best
> choice for the default value is `iso-2022-7bit' which all
> Emacsen (with Mule) support.

Ok; I'll make this change.

> Putting the coding cookie to the rc file would also be good.  It
> enables people to manually edit the rc file safely and informs
> non-Mule XEmacs whether the contents can be used and modified.

What should the cookie look like?

> Mail-abbrevs is still useful.  So, I use
>
> (add-hook 'message-setup-hook (if (featurep 'xemacs)
> 				  'mail-aliases-setup
> 				'mail-abbrevs-setup))
>
> even if I set `message-mail-alias-type' to `ecomplete'.  How
> about making this option a list?

Will do.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: New completion mode

[Katsumi Yamaoka]

>>>>> In <m3lktywka7.fsf@quimbies.gnus.org> Lars wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> The regexp used in `message-put-addresses-in-ecomplete' causes
>> an infloop in XEmacs.

> Ok; done.

Thanks.  However, the present ecomplete code seems to be written
only for Emacs.  In XEmacs 21.4, I tried making aliases of some
missing functions, e.g., line-beginning-position, read-event,
etc., but the goal seems to be far beyond such workarounds.  (I
wish I had time to grapple with it, though.)

>> The completions list appears only when a user invokes the
>> `self-insert-command' command.  Especially in Japan, people use
>> various tools in order to write Japanese text.  Some tools
>> replace `self-insert-command' with the other command, e.g.,
>> `egg-self-insert-char', in many keys, and it is used even when
>> writing ASCII text.  So, we need to make changes in message.el
>> like the following:
>>
>> (defcustom message-self-insert-commands '(self-insert-command)

> Yup.  I wonder whether there's a simpler solution to make this work
> automatically.  The point of the check for `self-insert-command' was
> just to avoid having the code trigger on totally automatic header
> setup stuff.  (It would flash "No ecomplete matches" while generating
> the header.)

> But I don't see any obvious way to fix this, so I've installed your
> change.

So far I don't have an idea either, but I think it should be
improved more so that it might ignore key events in some
conditions[1].  I normally use two or more alphabet keys in a
certain mode even to enter a single Japanese letter when I write
recipient's full name in the To header, for example.  In such a
case, I don't want ecomplete to work, though it isn't so
annoying at present.

[1] It is not only the case where the FOO-minor-mode variable
indicates the status but also the case where we have to use some
function or other like `message-tamago-not-in-use-p' to detect
the condition.  We are using indeed various tools to enter
Japanese text.  So, things we can do might be a few after all.

>> Therefore, I make a proposal to add a variable like
>> `ecomplete-database-file-coding-system'.  I think the best
>> choice for the default value is `iso-2022-7bit' which all
>> Emacsen (with Mule) support.

> Ok; I'll make this change.

Excellent.

>> Putting the coding cookie to the rc file would also be good.  It
>> enables people to manually edit the rc file safely and informs
>> non-Mule XEmacs whether the contents can be used and modified.

> What should the cookie look like?

It will be a line which looks like the following put at the
beginning of a file:

;;; .ecompleterc -*- mode: emacs-lisp; coding: iso-2022-7bit -*-
;; This file is generated automatically by ecomplete.el.

However, it seems now to be unnecessary if `iso-2022-7bit' is
used.  Because both Emacs and XEmacs-Mule are successful in
detecting the coding system automatically.

>> Mail-abbrevs is still useful.  So, I use
>>
>> (add-hook 'message-setup-hook (if (featurep 'xemacs)
>> 				  'mail-aliases-setup
>> 				'mail-abbrevs-setup))
>>
>> even if I set `message-mail-alias-type' to `ecomplete'.  How
>> about making this option a list?

> Will do.

I'm going to confirm for a while whether it is really useful to
use mail-abbrevs together with ecomplete, since it might be
worrying unduly (and the name `message-mail-alias-type' is not
suitable to a list ;-).

Regards,

Re: New completion mode

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Thanks.  However, the present ecomplete code seems to be written
> only for Emacs.  In XEmacs 21.4, I tried making aliases of some
> missing functions, e.g., line-beginning-position, read-event,
> etc., but the goal seems to be far beyond such workarounds.  (I
> wish I had time to grapple with it, though.)

I'll compile Gnus for XEmacs and try getting it to work there, too.

> [1] It is not only the case where the FOO-minor-mode variable
> indicates the status but also the case where we have to use some
> function or other like `message-tamago-not-in-use-p' to detect
> the condition.  We are using indeed various tools to enter
> Japanese text.  So, things we can do might be a few after all.

It's a difficult problem determining that 1) it was the user that
inserted something and 2) the user's insertion is "complete", in a
way.  Some of the input methods in Emacs are pretty hairy...

>> What should the cookie look like?
>
> It will be a line which looks like the following put at the
> beginning of a file:
>
> ;;; .ecompleterc -*- mode: emacs-lisp; coding: iso-2022-7bit -*-
> ;; This file is generated automatically by ecomplete.el.
>
> However, it seems now to be unnecessary if `iso-2022-7bit' is
> used.  Because both Emacs and XEmacs-Mule are successful in
> detecting the coding system automatically.

Ok; then I won't put the cookie into the file.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen