* Keys in edit-abbrevs-mode
@ 2011-03-27 5:23 Leo
2011-03-27 16:33 ` Andreas Röhler
0 siblings, 1 reply; 4+ messages in thread
From: Leo @ 2011-03-27 5:23 UTC (permalink / raw)
To: emacs-devel
Hi all,
I wonder if we can change the key bindings in edit-abbrevs-mode to be
more in line with global bindings.
C-x C-s -- redefine and save to the default abbrev file
C-x C-w -- redefine and asked the user which file to save
It is a bit odd after C-x C-s in that edit-abbrevs buffer, users are
still asked whether to save their abbrevs when exiting Emacs.
Any comments?
Leo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keys in edit-abbrevs-mode
2011-03-27 5:23 Keys in edit-abbrevs-mode Leo
@ 2011-03-27 16:33 ` Andreas Röhler
2011-03-28 4:59 ` Leo
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Röhler @ 2011-03-27 16:33 UTC (permalink / raw)
To: emacs-devel; +Cc: Leo
Am 27.03.2011 07:23, schrieb Leo:
> Hi all,
>
> I wonder if we can change the key bindings in edit-abbrevs-mode to be
> more in line with global bindings.
>
> C-x C-s -- redefine and save to the default abbrev file
> C-x C-w -- redefine and asked the user which file to save
>
> It is a bit odd after C-x C-s in that edit-abbrevs buffer, users are
> still asked whether to save their abbrevs when exiting Emacs.
>
+1
Maybe introduce a customizable boolean ask-abbrev-buffer-safe, if not
existing.
Andreas
--
https://code.launchpad.net/~a-roehler/python-mode/python-mode-components
https://code.launchpad.net/s-x-emacs-werkstatt/
> Any comments?
>
> Leo
>
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keys in edit-abbrevs-mode
2011-03-27 16:33 ` Andreas Röhler
@ 2011-03-28 4:59 ` Leo
2011-03-28 10:09 ` Andreas Röhler
0 siblings, 1 reply; 4+ messages in thread
From: Leo @ 2011-03-28 4:59 UTC (permalink / raw)
To: Andreas Röhler; +Cc: emacs-devel
On 2011-03-28 00:33 +0800, Andreas Röhler wrote:
> +1
How about something like this:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5937#52
>
> Maybe introduce a customizable boolean ask-abbrev-buffer-safe, if not
> existing.
>
> Andreas
Do you think we still need ask-abbrev-buffer-safe? (I don't have a
precise picture about what that var supposed to do).
Leo
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keys in edit-abbrevs-mode
2011-03-28 4:59 ` Leo
@ 2011-03-28 10:09 ` Andreas Röhler
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Röhler @ 2011-03-28 10:09 UTC (permalink / raw)
To: Leo; +Cc: emacs-devel
Am 28.03.2011 06:59, schrieb Leo:
> On 2011-03-28 00:33 +0800, Andreas Röhler wrote:
>> +1
>
> How about something like this:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5937#52
>
>>
>> Maybe introduce a customizable boolean ask-abbrev-buffer-safe, if not
>> existing.
>>
>> Andreas
>
> Do you think we still need ask-abbrev-buffer-safe? (I don't have a
> precise picture about what that var supposed to do).
>
> Leo
>
That var should re-enable the old behavior if needed.
Just a precausion. Not sure about it.
Please permit some general remark.
First of all I'm happy seeing you tackling the abbrevs issue. Think
thats a field indead, where Emacs may play it's strength still much more
than now. Seeing some readiness for a still bigger success.
Have several ideas in the pipe, which I may present you - first one as
bug-report sent this morning.
Nonetheless keep an eye at the risks of changes.
As Emacs makes changes easy, thats a strength and a weakness alike.
Would assume some time is spent redoing earlier improvements.
Thats normal, however let's minimise these losses.
Thats all
Cheers
Andreas
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-28 10:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-27 5:23 Keys in edit-abbrevs-mode Leo
2011-03-27 16:33 ` Andreas Röhler
2011-03-28 4:59 ` Leo
2011-03-28 10:09 ` Andreas Röhler
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).