chumpage / chumpy-windows Goto Github PK

chumpy-windows is mirrored on the Emacsmirror, which is a large up-to-date collection of Emacs packages.

As the maintainer of the mirror I am trying to resolve feature conflicts that result from one package bundling libraries from another package. I suspect in most cases these libraries were included so that users would not have to find, download and install each dependency manually.

Unfortunately bundling also has negative side-effects: if the bundled libraries are also installed separately, then it is undefined which version actually gets loaded when the respective feature is required.

Initially that isn't a big problem but in many cases upstream changes are not included or only after a long delay. This can be very confusing for users who are not aware that some of the installed packages bundle libraries which are also installed separately. In other cases bugs are fixed in the bundled versions but the fixes are never submitted to upstream.

Also now that Emacs contains the package.el package manager there is a better way to not require users to manually deal with dependencies: add the package (and when that hasn't been done yet the dependencies) to the Melpa package repository. If make is required to install your make you might want to add it to the el-get (another popular package manager) package repository instead.

Alternatively if you want to keep bundling these libraries please move them to a directory only containing bundled libraries and add the file ".nosearch" to that directory. You can then load the library using something like this:

(or (require 'bundled nil t)
    (let ((load-path
           (cons (expand-file-name "fallback-libs"
                                   (or load-file-name buffer-file-name)
                                   load-path))))
      (require 'bundled)))

Of course if your version differs from the upstream version this might not be enough in which case you should make an effort to get your changes merged upstream.

chumpy-windows bundles at least the following libraries:

• spaces
• window-jump

Best regards,
Jonas

I found other files have separated repository. Are you planning to continue development in the separated repositories? If so, please make a repository for splitter.el too.

It becomes a problem for el-get:
dimitri/el-get#1034

BTW, if you are interested in hacking Emacs window management, checkout emacs-window-manager (e2wm):

• https://github.com/kiwanami/emacs-window-manager
• https://github.com/kiwanami/emacs-window-layout
• https://github.com/tkf/ne2wm

Could you please specify the license used by this package?

Assuming that you want to release under "the GPL v3 or any later version", the best way to do that would be to add this to the library header:

;; This file 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 3, or (at your option)
;; any later version.

;; This file is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <http://www.gnu.org/licenses/>.

You could also, or instead, add a LICENSE file containing the text of the GPL-3. But if you only add that file, then the "or (at your option) any later version" bit won't be known. I recommend that you do both.

If this is too noisy for you, then you could also add one of these following lines to the header. (I do however recommend against doing only that - a judge might decide that this is not sufficient.)

;; License: GNU General Public License version 3, or (at your option) any later version
;; License: GNU General Public License version 3, or any later version
;; License: GNU GPL version 3, or (at your option) any later version
;; License: GPL version 3, or (at your option) any later version
;; License: GPL version 3, or any later version
;; License: GPL v3, or (at your option) any later version
;; License: GPL v3, or any later version
;; License: GPL-3+

The 'q' key that is binded to quit-window function in many RO buffers behaves wrong with spaces.
The easiest way to reproduce it is to open some file, enter dired, push q -> it should go back to the opened file.
Now open the same file, enter dired, change space, return back to the previous one, hit 'q'. It won't go the file as previous. It will go back to some buffer that was visible in the other space.
EDIT: It doesn't seem to have anything to do with quit-restore parameter as I originally though. It seems to have something with (window-prev-buffers). Probably it would have to be saved by hand :-/