Switch to the next window, or, if there is only one
window, the next buffer.
If done repeatedly when there is only one window, keeps getting
different buffers from the buffer list
If you want to cycle through buffers, have you looked at the M-x
iswitchb-mode minor
- tag completion when adding new tags (to promote resuing existing
tags)
This could be easily done by using `completing-read' instead of
`read-string' as when searching for tags, but it would be hard to
combine this with supporting entering multiple tags with a comma in
This is an alternative to setnu.el. It works incrementally and can
number large files fast. As it redraws all visible line numbers after
each command, it can also recover from potential layout glitches.
Compiler warning:
,
| In linum:
| linum.el:87:6:Warning: `make-local-hook' is an
Writers of libraries that are not part of the Emacs distribution
are often more concerned about compatibility for users of
different releases and even different flavors of Emacs
(e.g. XEmacs).
They might be concerned, yes, but I don't think anyone can dictate
that a package author
2. The call to fit-frame in anything-maybe-fit-frame passes in 4
params. The 4th parameter to fit-frame was only added on July 21,
2007. Therefore, this causes breakage for anyone using a released
version of emacs or a CVS emacs that is not pretty recent. Since the
params are optional, you
Another problem:
3. If I use the fit-frame-inhibit-fitting-flag equivalent (setq
inhibit-fit-frame-flag nil), that prevents the fit-frame code from
executing; however, the modify-frame-parameters call in anything-maybe-
fit-frame still gets executed (which results in the existing frame
being
Oh, just one minor point (and this is for Tamas) - issue #1 still
hasn't been fixed:
1. (minor) There is a space at the beginning of (defun anything-
maybe-fit-frame () that should be removed.
It's not just cosmetic (or me being pedantic) - several elisp
functions assume defun's start
On 2006-03-09 10:54 +, [EMAIL PROTECTED] wrote:
Here's new version which doesn't use electric, so the pattern editing
is more natural.
GNU Emacs has locate.el included. What's the advantage of globalff over
locate.el?
Tamas will perhaps answer specifically for `globalff.el', but here
alacarte.el replaces icicles-menu.el.
It does not require Icicles, but it is much better with Icicles.
(Icicles is here: http://www.emacswiki.org/cgi-bin/wiki/Icicles.
alacarte.el
Description: Binary data
___
gnu-emacs-sources mailing list
http://www.emacswiki.org/emacs/TimeStamp
There is a trade-off between simplicity and flexibility, and
the solutions on the wiki favor simplicity over flexibility.
Here's my attempt to support the user's preference for
different date and time formats while still minimizing
keystrokes.
You can download it here:
http://www.emacswiki.org/emacs/wide-n.el
You can browse previous narrowings for each buffer, restoring them. More info:
http://www.emacswiki.org/emacs/MultipleNarrowings
___
gnu-emacs-sources mailing list
Dave + Emacs Maintainers,
It would be nice if boxquote be made available via GNU ELPA.
FWIW - Revision 1.22 is on MELPA:
http://melpa.milkbox.net/#/boxquote
(To reach the Emacs maintainers, the emacs-devel list or
`M-x report-emacs-bug' might be more effective than
gnu-emacs-sources.)
The correct list for this is help-gnu-em...@gnu.org.
___
gnu-emacs-sources mailing list
gnu-emacs-sources@gnu.org
https://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
> > (657 "Sequence Functions")
> > (481 "GNU Free Documentation License")
> > (372 "pcase Macro")
> > (363 "Special Properties")
> > (329 "Frame Layout")
> > (304 "Garbage Collection")
> > (303 "Low-Level Font")
> > (301 "Changing Files")
>
> These modes really
> dunno if I am alone in this case but I find this message quite useless
> in this state. Why not adding sort of a package description and/or
> what is new in this version ?
FWIW: I agree. It would be more useful to have (1) a brief description of the
package and (2) a brief description of the
Why is emacs-devel now a destination for such
announcements? If gnu-emacs-sources@gnu.org
isn't deemed enough for some reason, wouldn't
info-gnu-em...@gnu.org be more appropriate?
16 matches
Mail list logo
