dired-jump keybinding and autoload

dired-jump keybinding and autoload

[Stephen Berman]

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

Start Emacs with -Q, type C-x C-j, Emacs beeps and says "C-x C-j is
undefined".  Now type `M-x dired-jump' and you get a Dired buffer of the
default directory.  Type q to bury it, and now typing C-x C-j works and
brings up the default directory again.  The reason for this behavior is
that the command dired-jump from dired-x.el is autoloaded, but its
default global keybinding, C-x C-j, is not.  Since this keybinding is
conditioned on the value of the defcustom dired-bind-jump, it is not
possible to put the keybinding on an autoload cookie, as is done
e.g. with C-x d in dired.el.  But users can always change or eliminate
the keybinding anyway, so dired-bind-jump isn't really a very
interesting defcustom.  So, since the default value of dired-bind-jump
is t, I suggest eliminating dired-bind-jump and the condition on the
keybinding, and autoloading the latter.  Ditto for the keybinding of
dired-jump-other-window, and also autoload this command.

Steve Berman


2008-05-08  Stephen Berman  <Stephen.Berman@gmx.net>

	* dired-x.el (dired-bind-jump): Eliminate.
	Add key bindings for `dired-jump' and `dired-jump-other-window' as
	autoload cookies.
	(dired-jump-other-window): Add autoload cookie.


[-- Attachment #2: dired-x.el patch --]
[-- Type: text/plain, Size: 2128 bytes --]

*** /Users/steve/cvsroot/emacs/lisp/dired-x.el.~1.91.~	2008-05-06 17:54:02.000000000 +0200
--- /Users/steve/cvsroot/emacs/lisp/dired-x.el	2008-05-08 14:24:58.000000000 +0200
***************
*** 59,65 ****
  ;;
  ;;      dired-bind-vm
  ;;      dired-vm-read-only-folders
- ;;      dired-bind-jump
  ;;      dired-bind-info
  ;;      dired-bind-man
  ;;      dired-x-hands-off-my-keys
--- 59,64 ----
***************
*** 128,138 ****
    :type 'boolean
    :group 'dired-keys)
  
- (defcustom dired-bind-jump t
-   "*Non-nil means bind `dired-jump' to C-x C-j, otherwise do not."
-   :type 'boolean
-   :group 'dired-keys)
- 
  (defcustom dired-bind-man t
    "*Non-nil means bind `dired-man' to \"N\" in dired-mode, otherwise do not."
    :type 'boolean
--- 127,132 ----
***************
*** 324,335 ****
          :help "Enable or disable omitting \"uninteresting\" files")
        'dashes)))
  
- ;;; GLOBAL BINDING.
- (if dired-bind-jump
-     (progn
-       (define-key global-map "\C-x\C-j" 'dired-jump)
-       (define-key global-map "\C-x4\C-j" 'dired-jump-other-window)))
- 
  \f
  ;;; Install into appropriate hooks.
  
--- 318,323 ----
***************
*** 351,357 ****
  For more features, see variables
  
    `dired-bind-vm'
-   `dired-bind-jump'
    `dired-bind-info'
    `dired-bind-man'
    `dired-vm-read-only-folders'
--- 339,344 ----
***************
*** 496,501 ****
--- 483,489 ----
  \f
  ;;; JUMP.
  
+ ;;;###autoload (define-key ctl-x-map "\C-j" 'dired-jump)
  ;;;###autoload
  (defun dired-jump (&optional other-window)
    "Jump to dired buffer corresponding to current buffer.
***************
*** 530,535 ****
--- 518,525 ----
  		    (dired-omit-mode)
  		    (dired-goto-file file))))))))
  
+ ;;;###autoload (define-key ctl-x-4-map "\C-j" 'dired-jump-other-window)
+ ;;;###autoload
  (defun dired-jump-other-window ()
    "Like \\[dired-jump] (`dired-jump') but in other window."
    (interactive)
***************
*** 1751,1757 ****
    (list
     'dired-bind-vm
     'dired-vm-read-only-folders
-    'dired-bind-jump
     'dired-bind-info
     'dired-bind-man
     'dired-find-subdir
--- 1741,1746 ----

Re: dired-jump keybinding and autoload

[Stefan Monnier]

> brings up the default directory again.  The reason for this behavior is
> that the command dired-jump from dired-x.el is autoloaded, but its
> default global keybinding, C-x C-j, is not.  Since this keybinding is

The intention behind dired-x is to contain extensions to dired that
we do not want to provide by default.


        Stefan

Re: dired-jump keybinding and autoload

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> brings up the default directory again.  The reason for this behavior is
>> that the command dired-jump from dired-x.el is autoloaded, but its
>> default global keybinding, C-x C-j, is not.  Since this keybinding is
>
> The intention behind dired-x is to contain extensions to dired that
> we do not want to provide by default.

C-x C-j arguably is something we want to provide by default, I think, so
it should probably be moved from dired-x to dired proper.

-- 
David Kastrup

Re: dired-jump keybinding and autoload

[Stephen Berman]

On Thu, 08 May 2008 16:36:49 +0200 David Kastrup <dak@gnu.org> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> brings up the default directory again.  The reason for this behavior is
>>> that the command dired-jump from dired-x.el is autoloaded, but its
>>> default global keybinding, C-x C-j, is not.  Since this keybinding is
>>
>> The intention behind dired-x is to contain extensions to dired that
>> we do not want to provide by default.

Then dired-jump should not be autoloaded, should it?  That would also
fix the UI inconsistency (command autoloaded but not its global key
binding).  But...

> C-x C-j arguably is something we want to provide by default, I think, so
> it should probably be moved from dired-x to dired proper.

... I think this would be the best solution (for dired-jump; there are
still one or two other autoloaded commands in dired-x that according to
the logic of the expressed intention shouldn't be).

Steve Berman

Re: dired-jump keybinding and autoload

[Juri Linkov]

>> C-x C-j arguably is something we want to provide by default, I think, so
>> it should probably be moved from dired-x to dired proper.
>
> ... I think this would be the best solution (for dired-jump; there are
> still one or two other autoloaded commands in dired-x that according to
> the logic of the expressed intention shouldn't be).

`C-x C-j' is a global key binding, unlike other dired keys.  But I agree
that dired-jump is useful enough to deserve its global key binding,
and I know no other package that would conflict with it.

The only drawback of this command is that it doesn't allow reading
an arbitrary file name.  I propose to change its argument so that
`C-u C-x C-j' will read the file name from the minibuffer (with the
default to the current file name), and keep the existing key binding
`C-x 4 C-j' to use the other window.  This change could be made
after copying dired-jump to dired.el, because anyway it requires
rewriting to get rid of dired-x specific code like using dired-omit-mode.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired-jump keybinding and autoload

[Juri Linkov]

[On 2008-05-10 I wrote:]
> `C-x C-j' is a global key binding, unlike other dired keys.  But I agree
> that dired-jump is useful enough to deserve its global key binding,
> and I know no other package that would conflict with it.
>
> The only drawback of this command is that it doesn't allow reading
> an arbitrary file name.  I propose to change its argument so that
> `C-u C-x C-j' will read the file name from the minibuffer (with the
> default to the current file name), and keep the existing key binding
> `C-x 4 C-j' to use the other window.

This is implemented by the following patch:

=== modified file 'lisp/dired-x.el'
--- lisp/dired-x.el	2010-03-30 16:10:14 +0000
+++ lisp/dired-x.el	2010-05-18 22:50:16 +0000
@@ -506,16 +506,21 @@ (defun dired-very-clean-tex ()
 ;;; JUMP.
 
 ;;;###autoload
-(defun dired-jump (&optional other-window)
+(defun dired-jump (&optional other-window file-name)
   "Jump to dired buffer corresponding to current buffer.
 If in a file, dired the current directory and move to file's line.
 If in Dired already, pop up a level and goto old directory's line.
 In case the proper dired file line cannot be found, refresh the dired
-buffer and try again."
-  (interactive "P")
-  (let* ((file buffer-file-name)
+buffer and try again.
+When OTHER-WINDOW is non-nil, jump to dired buffer in other window.
+Interactively with prefix argument, read FILE-NAME and
+move to its line in dired."
+  (interactive
+   (list nil (and current-prefix-arg
+		  (read-file-name "Jump to dired file: "))))
+  (let* ((file (or file-name buffer-file-name))
          (dir (if file (file-name-directory file) default-directory)))
-    (if (eq major-mode 'dired-mode)
+    (if (and (eq major-mode 'dired-mode) (null file-name))
         (progn
           (setq dir (dired-current-directory))
           (dired-up-directory other-window)
@@ -539,10 +544,12 @@ (defun dired-jump (&optional other-windo
 		    (dired-omit-mode)
 		    (dired-goto-file file))))))))
 
-(defun dired-jump-other-window ()
+(defun dired-jump-other-window (&optional file-name)
   "Like \\[dired-jump] (`dired-jump') but in other window."
-  (interactive)
-  (dired-jump t))
+  (interactive
+   (list (and current-prefix-arg
+	      (read-file-name "Jump to dired file: "))))
+  (dired-jump t file-name))
 \f
 ;;; OMITTING.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired-jump keybinding and autoload

[Wojciech Meyer]

Hi,

> [On 2008-05-10 I wrote:]
>> `C-x C-j' is a global key binding, unlike other dired keys.  But I agree
>> that dired-jump is useful enough to deserve its global key binding,
>> and I know no other package that would conflict with it.

Jabber.el uses this binding as a prefix key.

Wojciech

Re: dired-jump keybinding and autoload

[Juri Linkov]

>>> `C-x C-j' is a global key binding, unlike other dired keys.  But I agree
>>> that dired-jump is useful enough to deserve its global key binding,
>>> and I know no other package that would conflict with it.
>
> Jabber.el uses this binding as a prefix key.

That's is the reason why I have a doubt about moving it out of dired-x.
Maybe for dired-jump we should find a new keybinding not used
by other packages?

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: dired-jump keybinding and autoload

[Drew Adams]

> >>> `C-x C-j' is a global key binding, unlike other dired 
> >>> keys.  But I agree that dired-jump is useful enough to
> >>> deserve its global key binding, and I know no other
> >>> package that would conflict with it.
> >
> > Jabber.el uses this binding as a prefix key.
> 
> That's is the reason why I have a doubt about moving it out 
> of dired-x. Maybe for dired-jump we should find a new
> keybinding not used by other packages?

Which "other packages"? Any and all that exist now or might ever be created?

Jabber.el is not part of the Emacs distribution, AFAICT.

If, as you say, there is no code distributed with Emacs that uses `C-x C-j',
then that global binding should be fine for Emacs to use (modulo some other
reason against it).  At least I've never before noticed any reluctance to use
bindings that might be used by some 3rd-party code.

3rd-party bindings could be taken into consideration, all other things being
equal, but where would you draw the line?  Which 3rd-party code would merit
respecting its bindings?  Such code ranges from tiny, personal customizations to
giant, stable libraries used by many people for years.  Which bindings should
Emacs take care not to appropriate?

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Sun, May 23, 2010 at 6:45 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >>> `C-x C-j' is a global key binding, unlike other dired
>> >>> keys.  But I agree that dired-jump is useful enough to
>> >>> deserve its global key binding, and I know no other
>> >>> package that would conflict with it.
>> >
>> > Jabber.el uses this binding as a prefix key.
>>
>> That's is the reason why I have a doubt about moving it out
>> of dired-x. Maybe for dired-jump we should find a new
>> keybinding not used by other packages?
>
> Which "other packages"? Any and all that exist now or might ever be created?
>
> Jabber.el is not part of the Emacs distribution, AFAICT.
>
> If, as you say, there is no code distributed with Emacs that uses `C-x C-j',


More important: C-x C-j is reserved for Emacs internal use if I
understand it correctly.

See (info "(elisp) Key Binding Conventions"). I might be wrong since
that page does not mention C-x, but I think it should.

That C-x today happens to be a bad choice (because of CUA) is another
thing. I definitively does not get better if 3rd party libraries
starts using it too.

RE: dired-jump keybinding and autoload

[Drew Adams]

> More important: C-x C-j is reserved for Emacs internal use if I
> understand it correctly.

No, I don't see that anywhere.  Why would that be the case?

> See (info "(elisp) Key Binding Conventions"). I might be wrong since
> that page does not mention C-x, but I think it should.

You ask us to visit that node, but there is nothing there supporting your claim
- which you subsequently admit.  Just what would you like us to look for in that
node?

> That C-x today happens to be a bad choice (because of CUA) is another
> thing.

Sure is.  Unrelated, irrelevant, unimportant.

C-x today, yesterday, and tomorrow is an _excellent_ choice as an Emacs key
prefix.  It is easy-to-hand.  And it has been conventional in Emacs (and even
beyond) for over 30 years.

Saying that C-x is a bad choice because of CUA is like saying that driving on
the right side of the road is a bad choice because of Britain (or Japan or
India... - no flames please) - http://www.brianlucas.ca/roadside/.  When in
CUA-land, follow the rules of the CUA road, but don't expect folks across the
border to do the same.

> I definitively does not get better if 3rd party libraries
> starts using it too.

There is absolutely nothing wrong with users or 3rd-party code using the C-x
prefix.  Or else there is a new restriction/convention that I am not aware of.

The conventions stated in `(elisp) Key Binding Conventions' are long-standing
and pretty carefully thought out.  There are enough such restrictions, IMO.  I
do not support adding C-x to any list of bindings "reserved for Emacs internal
use".

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Sun, May 23, 2010 at 7:11 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> More important: C-x C-j is reserved for Emacs internal use if I
>> understand it correctly.
>
> No, I don't see that anywhere.  Why would that be the case?
>
>> See (info "(elisp) Key Binding Conventions"). I might be wrong since
>> that page does not mention C-x, but I think it should.
>
> You ask us to visit that node, but there is nothing there supporting your claim
> - which you subsequently admit.  Just what would you like us to look for in that
> node?


Please do not exaggerate. I want you to look at the keys reserved for
major modes!


>> That C-x today happens to be a bad choice (because of CUA) is another
>> thing.
>
> Sure is.  Unrelated, irrelevant, unimportant.


Why? This just looks like a rant.


> C-x today, yesterday, and tomorrow is an _excellent_ choice as an Emacs key
> prefix.  It is easy-to-hand.  And it has been conventional in Emacs (and even
> beyond) for over 30 years.


We have different opinions. Saying that it is an excellent choice is
an exaggeration. It is not an excellent choice in my opinion.


> Saying that C-x is a bad choice because of CUA is like saying that driving on
> the right side of the road is a bad choice because of Britain (or Japan or
> India... - no flames please) - http://www.brianlucas.ca/roadside/.  When in
> CUA-land, follow the rules of the CUA road, but don't expect folks across the
> border to do the same.


That would be nice, but would not that mean that all key bindings
should be changed when cua-mode is on? Or do you think CUA land is
outside of Emacs?


> There is absolutely nothing wrong with users or 3rd-party code using the C-x
> prefix.  Or else there is a new restriction/convention that I am not aware of.
>
> The conventions stated in `(elisp) Key Binding Conventions' are long-standing
> and pretty carefully thought out.  There are enough such restrictions, IMO.  I
> do not support adding C-x to any list of bindings "reserved for Emacs internal
> use".


All C-x bindings are absent from that page. I guess you do not mean
that a major mode could use any key bindings starting with C-x?

I have assumed that C-x is not mentioned because it is reserved for
Emacs. If not, then it should be mentioned on that info page to
clarify things.

But my opinion is very clear: Recommend that 3rd party libraries
should not use C-x as a prefix key.

RE: dired-jump keybinding and autoload

[Drew Adams]

> >> See (info "(elisp) Key Binding Conventions"). I might be 
> >> wrong since that page does not mention C-x, but I think it should.
>
> I want you to look at the keys reserved for major modes!

Nothing there about C-x (as you yourself acknowledged).
Nor should there be.

> > C-x today, yesterday, and tomorrow is an _excellent_ choice 
> > as an Emacs key prefix.  It is easy-to-hand.  And it has been
> > conventional in Emacs (and even beyond) for over 30 years.
> 
> We have different opinions. Saying that it is an excellent choice is
> an exaggeration. It is not an excellent choice in my opinion.

It is a _fact_ that C-x is very easy-to-hand (though admittedly not
super-ergonomic).

It is a _fact_ that C-x is not a self-inserting (insertable) char.
(It is, however, an ASCII control character, CAN
http://en.wikipedia.org/wiki/Cancel_character.)

It is a _fact_ that C-x is available nearly everywhere: in non-graphic terminals
as well as window managers. 

It is a _fact_ that C-x has been conventional in Emacs for decades.  (That alone
does not make it an excellent choice, of course, but it does offer a little
support for continuation.)

It is my _opinion_ that all of these facts together make C-x an excellent choice
as a _prefix_ key.  We are entitled to our own opinions, but the facts are
common.

(CUA has been a convention for nearly as long, of course, and it is wider than
Emacs.  But then no one has suggested doing away with CUA mode.)

> would not that mean that all key bindings should be changed
> when cua-mode is on? Or do you think CUA land is outside of Emacs?

Emacs CUA mode is part of Emacs.

As far as I am concerned, CUA mode can change any bindings it wants, especially
if the key-binding conventions you cited are respected.  I have no problem with
any CUA-mode bindings inside of CUA mode.

> All C-x bindings are absent from that page. I guess you do not mean
> that a major mode could use any key bindings starting with C-x?

Why not?

> I have assumed that C-x is not mentioned because it is reserved for
> Emacs. If not, then it should be mentioned on that info page to
> clarify things.

I do not believe that C-x is "reserved for Emacs".
Nor should it be.

The page does not attempt to mention everything that is _not_ reserved for
Emacs.  It just tries to give some guidelines.

> But my opinion is very clear: Recommend that 3rd party libraries
> should not use C-x as a prefix key.

Your opinion is clear.  And the reasons you gave are:

1. C-x is something different in CUA mode.

2. C-x as a prefix should be reserved for Emacs, if it is not already.

#2 is of course both the opinion and its rationale - infloop.

What about 3rd-party use of C-x as a non-prefix key?  Is that OK?  Could someone
define a new major or minor mode, say AUC-mode, that binds C-x to some action,
say `tuc'?

Should that be allowed for any 3rd-party library or just for emulation-mode
libraries?  Or just for libraries that emulate well-known key-binding
conventions?

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Sun, May 23, 2010 at 8:14 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
>> See (info "(elisp) Key Binding Conventions"). I might be wrong since
>> that page does not mention C-x, but I think it should.
...
>> I have assumed that C-x is not mentioned because it is reserved for
>> Emacs. If not, then it should be mentioned on that info page to
>> clarify things.
>
> I do not believe that C-x is "reserved for Emacs".
> Nor should it be.


So you answer boils down to this.

Let us clear this out. I think C-x should be mentioned and that it is
normally reserved for Emacs use (including cua-mode of course). You
think the opposite.

Whether it is reserved or not I think the status of it should be mentioned.

Chong, Stefan, what are your opinions?

RE: dired-jump keybinding and autoload

[Drew Adams]

> > I do not believe that C-x is "reserved for Emacs".
> > Nor should it be.
> 
> So you answer boils down to this.
> 
> Let us clear this out. I think C-x should be mentioned and that it is
> normally reserved for Emacs use (including cua-mode of course). You
> think the opposite.
> 
> Whether it is reserved or not I think the status of it should 
> be mentioned.

So even if it is not reserved, that non-reserved status should be mentioned?

Would you do the same for all non-reserved prefix keys?
For all non-reserved keys, prefix or not?

Would you point out (assuming it is not "reserved") that [f2] is a predefined
prefix key but to which you can add your own suffix keys?  And ESC?  And C-x 8
*?  And <header-line>?  And so on?

If George Carlin had taken that approach we wouldn't have the 7 dirty words.
We'd have an exhaustive treatise on all of the non-dirty words.
http://en.wikipedia.org/wiki/Seven_dirty_words

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Sun, May 23, 2010 at 10:56 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > I do not believe that C-x is "reserved for Emacs".
>> > Nor should it be.
>>
>> So you answer boils down to this.
>>
>> Let us clear this out. I think C-x should be mentioned and that it is
>> normally reserved for Emacs use (including cua-mode of course). You
>> think the opposite.
>>
>> Whether it is reserved or not I think the status of it should
>> be mentioned.
>
> So even if it is not reserved, that non-reserved status should be mentioned?


Yes, since it is an important key. It clashes with CUA and it is used
very frequently in Emacs.


> Would you do the same for all non-reserved prefix keys?
> For all non-reserved keys, prefix or not?
...
> If George Carlin had taken that approach we wouldn't have the 7 dirty words.
> We'd have an exhaustive treatise on all of the non-dirty words.
> http://en.wikipedia.org/wiki/Seven_dirty_words


Merriam Webster?

Re: dired-jump keybinding and autoload

[Stephen J. Turnbull]

Lennart Borgman writes:

 > That C-x today happens to be a bad choice (because of CUA) is another
 > thing. I definitively does not get better if 3rd party libraries
 > starts using it too.

You're totally missing your own point.  It is precisely CUA that makes
C-x an excellent choice of prefix for new bindings.

CUA currently conflicts with all C-x bindings, and this is a
non-trivial problem to solve because of Emacs history.  But you are
absolutely, completely, 100.0% wrong.  Adding new C-x bindings does
not make this problem worse.  If and when it is (really) solved, it
will need to be solved for all C-x bindings in one fell swoop, and
that solution will be applicable to any future C-x bindings, which
will be less likely to conflict with existing C-x bindings because
they will be chosen not to conflict.

Why make that solution harder by spreading alternate prefix keys all
over the map (literally)?

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Mon, May 24, 2010 at 3:01 AM, Stephen J. Turnbull
<turnbull@sk.tsukuba.ac.jp> wrote:
> Lennart Borgman writes:
>
>  > That C-x today happens to be a bad choice (because of CUA) is another
>  > thing. I definitively does not get better if 3rd party libraries
>  > starts using it too.
>
> You're totally missing your own point.  It is precisely CUA that makes
> C-x an excellent choice of prefix for new bindings.
>
> CUA currently conflicts with all C-x bindings, and this is a
> non-trivial problem to solve because of Emacs history.  But you are
> absolutely, completely, 100.0% wrong.  Adding new C-x bindings does
> not make this problem worse.  If and when it is (really) solved, it
> will need to be solved for all C-x bindings in one fell swoop, and
> that solution will be applicable to any future C-x bindings, which
> will be less likely to conflict with existing C-x bindings because
> they will be chosen not to conflict.


You have a point there of course. I get too upset when this conflict
is ignored.. ;-)

There are some thing there I do not understand:

-. Does all C-x bindings go into Control-X-prefix? How does that work?

- Why is Control-X-prefix a full keymap (and not a sparse dito)?

Re: dired-jump keybinding and autoload

[Stephen J. Turnbull]

Lennart Borgman writes:

 > You have a point there of course. I get too upset when this conflict
 > is ignored.. ;-)

Well, you're just going to have to deal with that.  I sympathize with
your pain, but not with your position.  I prefer X-style GUI and Emacs
keybindings myself. :-)  Since that seems to the be majority position
in Emacs core, I think the only solution for people who want CUA
bindings (or other nontraditional maps, such as vi[1]) is going to be
a really excellent keymap skinning method that allows even more
convenient switching (and maintenance of personal variants) than
cua.el or viper.

 > There are some thing there I do not understand:
 > 
 > -. Does all C-x bindings go into Control-X-prefix? How does that work?

Yes and no.  The basic answer is "yes, because the control-X prefix
map is bound early, and the keybinding code automatically searches
through the maps found along the keystroke sequence, and puts bindings
in the leaf-most map it finds."

The full answer is "theoretically, not necessarily, because you can
unbind C-x in a mode before binding C-x sequences, but in practice
only someone intent on sabotage would do that in an editing mode".  I
can't recall ever typing C-x C-f and getting something other than
find-file (including errors), or C-x b and getting something other
than switch-to-buffer, so I would guess that even rather specialized
modes pretty much all preserve the binding of control-x to that
keymap.

 > - Why is Control-X-prefix a full keymap (and not a sparse dito)?

Saves some consing, that's all.  Eg, in XEmacs they're both resizable
hashtables, make-sparse-keymap starts with room for 8 entries (and the
hashtable implementation rounds up to 19), while make-keymap makes a
much bigger one (at least 60 entries which rounds up to 79 -- not
quite big enough, my current session has 82 entries :-) by default.
Otherwise the functionality of both kinds of keymap is identical.

In Emacs the implementation is different, but I would imagine that the
rationale is the same, a tradeoff of consing vs a certain amount of
space, and the API has exactly the same semantics for both kinds of
hashtable.


Footnotes: 
[1]  For values of tradition == Emacs', of course!

Re: dired-jump keybinding and autoload

[Leo]

On 2010-05-23 17:04 +0100, Juri Linkov wrote:
> That's is the reason why I have a doubt about moving it out of
> dired-x. Maybe for dired-jump we should find a new keybinding not used
> by other packages?

If you choose other key, people who have been using dired-x will have
difficult time and dired-x is shipped with emacs for a while now. Jabber
can choose to override global binding, in particular, I guess jabber
isn't visiting any files in its buffers.

I think dired-jump should be moved out of dired-x. Those redefined
functions should be properly merged too. Redefining functions are
dependent on the order the library is loaded and causes confusion from
time to time.

Leo

Re: dired-jump keybinding and autoload

[Juri Linkov]

> If you choose other key, people who have been using dired-x will have
> difficult time and dired-x is shipped with emacs for a while now.

We could keep `C-x C-j' in dired-x, or after moving dired-jump out of
dired-x, change the default value of dired-bind-jump to nil.  I.e.
not to make it a global keybinding by default, so to not change the
current status quo.

Finding a better non-conflicting key is another question.  For instance,
there are many free keys on the M-g ("goto") prefix.  I remember some
suggestions were `M-g j', `M-g d', or `M-g f'.

Since `C-x C-j' is almost a duplicate of `C-x d' (they both
switch to the Dired buffer), maybe a better key for dired-jump
would be `C-x C-d'.

Does anyone use `list-directory' currently bound to `C-x C-d'?

> I think dired-jump should be moved out of dired-x. Those redefined
> functions should be properly merged too. Redefining functions are
> dependent on the order the library is loaded and causes confusion from
> time to time.

dired-jump uses another feature of dired-x - it toggles omitting with
dired-omit-mode.  So at the first step dired-omit-mode should be moved
out of dired-x before dired-jump.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Mon, May 24, 2010 at 6:00 PM, Juri Linkov <juri@jurta.org> wrote:
>
> Since `C-x C-j' is almost a duplicate of `C-x d' (they both
> switch to the Dired buffer), maybe a better key for dired-jump
> would be `C-x C-d'.

Maybe `C-x D'?

> Does anyone use `list-directory' currently bound to `C-x C-d'?

If you use dialog boxes I think you need it.

RE: dired-jump keybinding and autoload

[Drew Adams]

> > Since `C-x C-j' is almost a duplicate of `C-x d' (they both
> > switch to the Dired buffer), maybe a better key for dired-jump
> > would be `C-x C-d'.
> 
> Maybe `C-x D'?

If you do not object to `C-x D' simply because it is on the `C-x' prefix, how
can there be any objection to `C-x C-j' on the same grounds?

So it sounds to me like there is no objection to using `C-x C-j'.

And Juri's "finding a better non-conflicting key" is a non-problem:
`C-x C-j' is _not_ a conflicting key in any way.  It is a free global binding
that does not conflict with any bindings made by any code distributed with
Emacs.

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Mon, May 24, 2010 at 6:46 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Since `C-x C-j' is almost a duplicate of `C-x d' (they both
>> > switch to the Dired buffer), maybe a better key for dired-jump
>> > would be `C-x C-d'.
>>
>> Maybe `C-x D'?
>
> If you do not object to `C-x D' simply because it is on the `C-x' prefix, how
> can there be any objection to `C-x C-j' on the same grounds?


I think Stephen was right. There will not be more trouble using `C-x
C-j' because the keys on C-x can be moved by moving Control-X-prefix.

So I have no objections. I would rather see that we implement
something like Control-X-prefix for all prefix keys. That would
finally open up for moving C-x for those who wants it.


> So it sounds to me like there is no objection to using `C-x C-j'.
>
> And Juri's "finding a better non-conflicting key" is a non-problem:
> `C-x C-j' is _not_ a conflicting key in any way.  It is a free global binding
> that does not conflict with any bindings made by any code distributed with
> Emacs.
>
>

RE: dired-jump keybinding and autoload

[Drew Adams]

> Since `C-x C-j' is almost a duplicate of `C-x d' (they both
> switch to the Dired buffer), maybe a better key for dired-jump
> would be `C-x C-d'.
> 
> Does anyone use `list-directory' currently bound to `C-x C-d'?

Yes, why not? That binding has been available since Day One. Why start playing
musical chairs here?

I do not understand what is wrong with using `C-x C-j' (globally).

There was no objection raised to that, AFAICT. Except for one email about a
library (jabber.el) that is not distributed with Emacs (hence irrelevant here),
Lennart was the only one to speak about the binding, I think. And Lennart's
objection was to using _anything_ involving `C-x'.

Re: dired-jump keybinding and autoload

[Miles Bader]

Wojciech Meyer <wojciech.meyer@googlemail.com> writes:
>>> `C-x C-j' is a global key binding, unlike other dired keys.  But I agree
>>> that dired-jump is useful enough to deserve its global key binding,
>>> and I know no other package that would conflict with it.
>
> Jabber.el uses this binding as a prefix key.

Then jabber.el will either have to change its binding, or lose the
dired-jump functionality in jabber buffers.  Of course, since jabber
doesn't sound like a file-visiting mode in the first place, the latter
probably doesn't matter so much....

-Miles

-- 
Selfish, adj. Devoid of consideration for the selfishness of others.

Re: dired-jump keybinding and autoload

[Wojciech Meyer]

Well the trouble is that those jabber.el keybindings are global. Means
C-x C-j C-r will show the roster whereever I am. If its a file buffer
then the mentioned key stroke will visit dired. I agree that dired-x
has been around for longer and also that it is just one keybinding.
Wojciech

On 5/24/10, Miles Bader <miles@gnu.org> wrote:
> Wojciech Meyer <wojciech.meyer@googlemail.com> writes:
>>>> `C-x C-j' is a global key binding, unlike other dired keys.  But I agree
>>>> that dired-jump is useful enough to deserve its global key binding,
>>>> and I know no other package that would conflict with it.
>>
>> Jabber.el uses this binding as a prefix key.
>
> Then jabber.el will either have to change its binding, or lose the
> dired-jump functionality in jabber buffers.  Of course, since jabber
> doesn't sound like a file-visiting mode in the first place, the latter
> probably doesn't matter so much....
>
> -Miles
>
> --
> Selfish, adj. Devoid of consideration for the selfishness of others.
>

-- 
Sent from my mobile device

Re: dired-jump keybinding and autoload

[Lennart Borgman]

On Mon, May 24, 2010 at 9:19 AM, Wojciech Meyer
<wojciech.meyer@googlemail.com> wrote:
> Well the trouble is that those jabber.el keybindings are global. Means
> C-x C-j C-r will show the roster whereever I am. If its a file buffer
> then the mentioned key stroke will visit dired. I agree that dired-x
> has been around for longer and also that it is just one keybinding.
> Wojciech


Are they globally? That is bad.

External packages should of course not make global key bindings. Maybe
(info "(elisp) Key Binding Conventions") need to clarify that?

Re: dired-jump keybinding and autoload

[Miles Bader]

Wojciech Meyer <wojciech.meyer@googlemail.com> writes:
> Well the trouble is that those jabber.el keybindings are global.

Probably should change them then.

-Miles

-- 
One of the lessons of history is that nothing is often a good thing to
do, and always a clever thing to say.  -- Will Durant