On GNU Emacs 21.3.50.1 (i386-mingw-windows98.3000) of 2005-01-30 on
NONIQPC I write the following variant of `clone-indirect-buffer':
(defun my-clone-buffer ()
(interactive)
(make-indirect-buffer
(current-buffer) (generate-new-buffer-name (buffer-name)) t))
I now open a larger file say
With GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2005-04-11.
There are string/nil mismatches in the standard customization settings
of `jka-compr-compression-info-list'.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
On GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2005-04-11 imenu
creates _two_ entries for, say
static void
describe_abbrev (sym, stream)
Lisp_Object sym, stream;
with the first entry referencing static and the second describe and
only _one_ for
static void describe_abbrev (sym, stream)
On GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2005-04-11:
`beginning-of-defun' in cperl-mode always moves to the beginning of the
buffer. Removing the last (right) parenthesis from
`defun-prompt-regexp' in cperl-mode.el seems to resolve the problem.
Recent changes to `editfns.c' (and `fileio.c') let `make bootstrap' fail
with mingw.
gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c -g
-march=i686 -O2 -Di386 -D_CRTAPI1=_cdecl -Demacs=1 -DWINDOWSNT
-DDOS_NT -DHAVE_CONFIG_H -I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1
From the Elisp manual:
-- Function: add-to-invisibility-spec element
This function adds the element ELEMENT to
`buffer-invisibility-spec' (if it is not already present in that
list). ...
But the element is added unconditionally:
(defun add-to-invisibility-spec (arg)
...
(setq
Suppose I start with a single window called W1 (window names are
fictional)
W1
split W1 horizontally
W1 | W2
split W2 vertically
| W2
W1 |---
| W3
delete W1
W2
--
W3
split W2 horizontally
W2 | W4
---
W3
split W4 vertically
| W4
W2 |---
| W5
---
W3
and delete W2
W4
--
W5
Both `hack-local-variables' and `hack-one-local-variable' may call
`switch-to-buffer' when parsing local variables. As a consequence, a
save-window-excursion: Cannot switch buffers in a dedicated window
error is generated when calling `find-file-noselect' while the
selected window is dedicated.
Any objection against this patch?
No objections, thanks
martin
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
The issues listed below are not very troubling. I came accross them
when I tried to install a before-string at bob that does _not_ get
highlighted when `point' equals `point-min'. That's the only one I
really care about and did not get around. Anyway, here is the list:
A. Highlighting and face
Putting `mark' before S and `point' after T highlights the entire
overlay but not its after-string.
That in itself might be ok.
Agreed. But in this case a before-string should not get highlighted
either when the associated overlay is highlighted. I'd classified such
highlighting
/* Compare two overlay_entry structures E1 and E2. Used as a
comparison function for qsort in load_overlay_strings. Overlay
strings for the same position are sorted so that
1. All after-strings come in front of before-strings, except
when they come from the same overlay.
I
`delphi.el' has nil mismatch in:
(defcustom delphi-other-face nil
*Face used to color everything else.
:type 'face
:group 'delphi)
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
Richard M. Stallman wrote:
Setting the value to the face `default' (which produces the desirable
visual effect) is not exactly the same as a nil value.
When you say it is not exactly the same, could you explain what that
means? The two values are not eq, of course--is that what you
Perhaps we should define nil as a face that has no attributes.
Then it would work to set any face-valued variable to nil.
What do people think of that?
Just to make things clear for myself: An Elisp `face' is not a primitive
type like say `integer' or `overlay'. It's merely a set of
Thanks for the patient explanations.
If FACE is empty the display engine interprets the semantics of
FACE
I am not sure what situation you're talking about. Where in the data
structure was nil encountered?
I needlessly complicated things here. All I wanted to say is that the
The Emacs Lisp manual specifies the window property of an overlay as:
`window'
If the `window' property is non-`nil', then the overlay applies
only on that window.
Executing
(defun foobar ()
(interactive)
(insert foo)
(let ((overlay (make-overlay (- (point) 3) (point
foo
---
ba
to
foo
---
bar
which to my knowledge neither font-lock nor jit-lock can handle.
I'm tempted to say no, that should work just fine. But really, it all
depends on many more details of how foo and bar relate.
When
foo
---
ba
is fontified you have two choices: (a) Don't set a
jit-lock breaks font-lock's handling of syntax-table properties anyway.
Having syntactic properties behave correctly only for positions
preceding `font-lock-syntactically-fontified' means that I can't parse
text after that position reliably with
And as mentioned above, if font-lock is turned off the same parsing function
will equally be unable to rely on the syntax-table properties. So the only
situation where the problem cannot be reproduced without jit-lock is when
this parsing function is only used in font-lock and when it parses
Half-baken ideas ahead - don't pay too much attention.
I believe that `jit-lock-after-change'
should contain something like
(setq font-lock-syntactically-fontified
(min font-lock-syntactically-fontified start))
Note that jit-lock is supposed to be a generic framework
Setting syntax-begin-function is not enough because currently the
font-lock-syntactically-fontified logic does not take advantage of
syntax-begin-function.
A short excursion:
-- Function: syntax-ppss optional pos
This function returns the state that the parser would have at
Unless/until you can think of a better solution consider the following
patches as point of departure (I know, you despise yet another text
property):
*** font-lock.elWed Oct 19 16:35:24 2005
--- font-lock.elFri Nov 4 13:38:08 2005
***
*** 501,506
--- 501,502
The bug seems related to the following change from 1997-06-20:
(widget-after-change): Don't apply :notify here.
(widget-before-change): New function. Apply :notify here.
`widget-before-change' may modify text preceding the editable field. As
a consequence FROM and TO values
`widget-before-change' may modify text preceding the editable field. As
a consequence FROM and TO values passed to `widget-after-change' get
messed up.
I don't entirely understand the reasoning. Why can
`widget-before-change' modify that text? Is this solely because of
doing
:notify will now change the text following the State button from SAVED
and set. to EDITED, shown value does not take effect until you set or
save it. The first of these strings is 14 characters long, the second
66. The difference of their length is 52.
I see.
This edit
That's because overlays of these button don't get copied from the
temporary buffer. Is there a function that can copy them to another
buffer?
I tried to address that issue in
http://lists.gnu.org/archive/html/emacs-devel/2005-11/msg01179.html
With Emacs -Q do M-x customize-face RET lazy-highlight RET
[ ] Foreground: *
[X] Background: paleturquoise (sample)
[ ] Stipple: *
[ ] Inherit: *
uncheck the box preceding Background
[ ] Foreground: *
[ ] Background:
The following patch should assert that FROM is correct when
`after-change-functions' is called (without any warranty).
*** insdel.cSat Nov 5 20:46:36 2005
--- insdel.cSat Dec 17 18:22:00 2005
***
*** 749,757
{
if (nbytes 0)
{
! int opoint = PT;
!
Do M-x customize-face RET bold RET
Invoke `State' and select `Add comment'
Invoke `State' and select `Erase Customization'
Gets me:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
set-buffer(nil)
(save-current-buffer (set-buffer (widget-field-buffer widget))
My last build where this worked correctly is from 2005-10-20. A build
from 2005-11-06 already doesn't have the doc-strings. In between was:
2005-10-31 Dan Nicolaescu [EMAIL PROTECTED]
* loadup.el: Load emacs-lisp/syntax, font-lock and jit-lock so
that global-font-lock-mode
On what OS? (Please always tell that, since the configury and build
setups are different on some systems.)
In GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) on WindowsME.
but - strangely enough - dnd, tool-bar, ... retained their doc-strings.
Not for me, not on MS-Windows.
I lied, only
`custom-quote' is still defined in cus-edit.el. Compare
2002-04-19 Miles Bader [EMAIL PROTECTED]
* custom.el (customize-mark-to-save, customize-mark-as-set)
(custom-quote): Moved here from `cus-edit.el'.
* cus-edit.el (customize-mark-to-save, customize-mark-as-set)
When `clean-buffer-list' kills the base-buffer of an indirect buffer
_before_ it is able to kill the indirect buffer, the indirect buffer
gets killed too. In this case invoking `midnight-buffer-display-time'
when called with the killed indirect buffer as argument will result in a
When skipping a generic comment backwards `forward-comment' doesn't
update count1. As a consequence (forward-comment -1) skips all generic
comments preceding point. The trivial patch below should resolve this.
2006-04-29 Martin Rudalics [EMAIL PROTECTED]
* syntax.c (Fforward_comment
the inconvenience
2006-05-01 Martin Rudalics [EMAIL PROTECTED]
* syntax.c (Fforward_comment): Detect generic comment at beginning of
buffer when moving backwards.
*** syntax.cMon May 1 10:08:58 2006
--- syntax.cMon May 1 10:13:46 2006
***
*** 2123,2130
There are window managers that does not allow focus changes outside the
window
that has the mouse in it, if focus follows mouse. Metacity and sawfish
calls this mode focus-follows-mouse-strict. In that case, the code
above moves the mouse to the new window so it gets the focus. It is not
... you have to explicitly click on the desktop in order
to give it focus.
That's the default, yes. But one can tweak the Registry to force
Windows behave more like X, in that just entering a window with the
mouse gives it focus. (I do this on any Windows machine I need to
work on,
It would be interesting if someone could repeat my experiment by
calling file-attributes on the same file from both emacs 21 and 22,
and reporting if both versions return identical time values.
With GNU Emacs 21.2.1 (i386-msvc-windows98.3000) of 2002-03-19 on buffy:
(nil 1 123 123 (17594
Bug squashed, I think. The patch is below (I already committed it to
CVS); please see if this solves the problem.
It solves the problem for me, thanks Eli.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Please try
$ strace firefox
$ strace emacs
Notice that after things settle, firefox gives the CPU or whatever
several seconds of rest between polling etc. activity, whilst emacs
causes a constant stream.
I notice when I exited emacs, my laptop fan soon was able to take rest
breaks. With an
Now you've really done it. M-x fill-paragraph on
487.2875,
487.3375,
487.4000,
487.4500,
487.4750,
487.5250,
487.5500,
487.6000,
487.7250,
487.8000,
487.8500,
487.8750,
gives
487.2875, 3375, 4000, 4500, 4750, 5250, 5500, 6000, 7250, 8000, 8500,
487.8750,
OK, probably well intentioned, but not
Hi Simon
src/emacs -Q
(setq mouse-autoselect-window 3) C-x C-e C-x 2
And select the lower window. Move quickly from the lower window up to the
menu bar and select the Help menu. While holding down mouse-1, move quickly
to the upper window (ie, but off the Help menu pane). Wait until the
Start with
emacs -Q
Open a file and do
M-x untabify
I get the error
The mark is not set now, so there is no region
Isn't that by design?
(defun untabify (start end)
Convert all tabs in region to multiple spaces, preserving columns.
Called non-interactively, the region is
Hi Martin, I do get this problem with the default 0.5s delay. At least, I
do see a problem of occasional switching window during menu use. I found
this particular problem when I upped the delay to 3s to try to make it
easier to reproduce/understand what I was seeing in normal use. What's
Actually, with my setup, I don't see it. The selection does happen (I
debugged it) but redisplay does not occur (or does not show it). You might
remember this sort of thing sometimes happened when I tested earlier
autoselect delay implementations.
It's true, redisplay may be inhibited
The function I wrote just returned Qnil/Qt based on popup_activated(), which
is non-zero if the menu-bar or a popup-menu is active. That includes dialog
boxes.
Fine. However, as I said before it doesn't work this way neither on w32
nor on mac. Anyway, please send me just the code of that
I don't have cygwin installed. I think `cp' of msys is used for copying
files while `make install'.
FWIW, `make install' recently failed with cp.exe (5.3.0) from GnuWin32 on
my system. It tells me things like:
... skipping file `c:/foo', as it was replaced while being copied
This never
Please post a full transcript of what happens when you type
make install. It's very hard to look into problems given
such partial information.
It's not a problem with `make install'. It's a problem of that
very instance of cp. As far as I recall it failed already during
configure, hence I
FWIW, I'm using the same version of cp.exe, and I don't see any such
problem, neither during configure, nor during make install.
I didn't before and do not since I eliminated that version of cp. As I
said before, it's not related to making Emacs. cp.exe from GnuWin32
simply refuses to copy a
Please try whether the attached patch works. If
`mouse-autoselect-window-suspend' causes any problems I'll take it out.
The patch also removes `popup_activated_flag' and `popup_activated' from
w32menu.c since these are completely useless. In addition I removed a
confusing disjunct from
Menu selection functions on Mac (MenuSelect and PopUpMenuSelect) do
not return until the user selects an menu item or cancels the menu
selection. So I think menu-or-popup-active-p can always return Qnil
on Mac.
Thanks for the information. Hence
DEFUN (menu-or-popup-active-p,
If the purpose is to know if some menu is *currently* active, then the
function will DTRT because Lisp evaluation never happens during menu
selection on Mac.
Thanks again for explaining this.
The welcome message is shown in the lower window, and the upper window
gets selected immediately
Thanks, seems to work under X. Do you need (fboundp
'menu-or-popup-active-p)?
I'll remove that.
I'm not sure if waiting on average (1.5 * delay) is better than (0.5 *
delay), but it's fine by me as it is.
I've been driven by the consideration that waiting at least (1.0 *
delay) is better
Increment of the counter is suspended during the file dialog/menu
operation. And after the operation, the timer fires multiple times
continuously until the counter catches up the value that it would be
if no file dialog/menu were activated.
Weird. Suppose `mouse-autoselect-window-select'
My description above is about the count-up example in Simon's message.
You can observe a similar behavior using the example and M-! sleep 5
RET
I see, delayed window autoselection turns itself off in that case.
Anyway, does it make sense that a timer fires more frequently than
prescribed by
Funnily enough, weird was the exact word I used in an email too. But then
I thought buffering up the timers to run later might be the most logical
thing to do, in the circumstances. Maybe it makes more sense than not
running the timers at all. After all, as I'm sure the documentation aught
You learn something every day. At least, I do about Emacs.
`timer-max-repeats' is the maximum number of times to repeat a timer,
if real time jumps. Hence, there is an upper bound on the number of
times such timer run.
I think the Elisp manual should mention two things: (1) That a timer can
I was thinking that it would also simplify mouse-autoselect-window-cancel,
to avoid the tests specific to scrolling, but now I see maybe that's not the
case.
The test in `mouse-autoselect-window-cancel' serves to avoid that the
pre-command hook cancels autoselection while scrolling. I could
`timer-max-repeats' is the maximum number of times to repeat a timer,
if real time jumps. Hence, there is an upper bound on the number of
times such timer run.
The doc string says this applies when real time jumps, such as when
Currently, just a comment in `timer-event-handler'
I just caught Emacs hogging the CPU with endless
redisplay/fontification. The following code triggers it for me:
--8---cut here---start-8---
(progn
(switch-to-buffer *fontification loop*)
(emacs-lisp-mode)
(while ( (point) (floor (* (sqrt 2)
Can you use the Lisp debugger to see what is calling the
fontification-functions?
They're called via redisplay (handle_fontified_prop in xdisp.c). The
redisplay itself is triggered by a timer calling
jit-lock-fontify-again, which in turn is repeatedly setup by
jit-lock-fontify-now.
ISTM
We could define `find-function-regexp' as:
(defcustom find-function-regexp
;; Match things like (defun foo ...), (defmacro foo ...),
;; (define-skeleton foo ...), (define-generic-mode 'foo ...),
;; (define-derived-mode foo ...), (define-minor-mode foo)
(concat
Seems as function `list-at-point' from thingatpt.el
fails.
Currently `list-at-point' does `up-list' followed by `backward-sexp'
followed by another `up-list' which doesn't make sense. Please look at
the attached - largely untested - patch which also tries to handle the
problem that
It looks like we could speed it up even more
by producing this list
! (setq whitespace-retval (cons (match-beginning 0)
whitespace-retval))
only if it is actually wanted. Calling from whitespace-buffer
could pass t as an optional argument saying do produce this list.
We could
I forgot to say that I can't follow Peter's argument that older 2006 Emacsen
didn't have this problem. I tried with a couple of versions starting with a
mid-2005 one and all exhibited the same behavior as the most recent one.
___
emacs-pretest-bug
With symbol-at-point however, I intend to drop the
(if thing (intern thing))
form when called.
FWIW, the `intern' call has been inserted around July/August 2006 but I
couldn't find a suitable ChangeLog entry. Stefan did you write that?
___
[...]
1.36 (monnier 04-Jul-06): (if thing (intern thing
[...]
and `L' prints the same entry as in lisp/ChangeLog:
,[ lisp/ChangeLog ]
| 2006-07-04 Stefan Monnier [EMAIL PROTECTED]
|
| * thingatpt.el (symbol-at-point): Don't use `form-at-point' which
| fails if
Try C-x v ~ 1.35 to see the code before my change (or try C-x v = to
see the diff between 1.35 and 1.36). You'll see that the previous code
returned a symbol, not a string.
Silly me. I stubbornly decided the previous code returned a string
built from word and symbol constituents. Apologies
What shall I check exactly here? I ran this white() and yes, it
finishes in 1-2 seconds. However I also ran (M-:)
(whitespace-buffer-search whitespace-ateol-regexp) and it also took
1-2 seconds on my problematic original source file (it has only one
eol error).
However with my slowtst.el I
Attached find patch and ChangeLog entry for this.
* whitespace.el (whitespace-indent-regexp): Make this match any
multiples of eight spaces near the beginning of a line.
(whitespace-buffer): Use `remove-overlays' instead of
`whitespace-unhighlight-the-space' to
Interesting things again! I tried this latest whitespace.el and found
the followings:
1. whitespace-buffer on slowtst.el takes ~9 seconds (=the same result
what I got with your previous fix) IF point is at the beginning of the
buffer. If point is somewhere down (e.g. at (point-max))
I tried M-: (remove-overlays nil nil 'face 'whitespace-highlight) and
it took about the same time what was the increment between first and
other runs. Evaluating it when point is at bottom, very fast, but when
point is at top, it is slow.
I think you can easily test it by making slowtst.el
Thanks for your prompt answer!
Yes, with this last fix finally whitespace-buffer seems to be quite
fast each time.
Thanks for you cooperation. Please keep an eye on this.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
and w32menu.c.
My problem is that `menu-or-popup-active-p' should return nil even in
the case where you build without menus. Hence I propose the attached
patch. Please try whether it works on your system.
Thanks again
martin rudalics.
*** macmenu.c Mon Nov 6 10:23:06 2006
--- macmenu.c Mon Nov 6
If you've found a slowness in remove-overlays, could you aim to make
that function faster, rather than making its caller faster by not using
remove-overlays?
Using `remove-overlays' to delete all overlays with a given property is
overkill. The tests
(if ( (overlay-start o) beg)
So, if I understand you correctly, the change to make is to replace
(remove-overlays nil nil 'face 'whitespace-highlight)
(overlay-recenter (point-max))
with
(overlay-recenter (point-max))
(remove-overlays nil nil 'face 'whitespace-highlight)
Is that right?
Right.
I've just noticed that you added
(overlay-recenter (point-max))
to `remove-overlays'. That might cause a slowdown if you remove
overlays near bob and there are many overlays between the ones you
remove and eob. Please consider replacing this by
(overlay-recenter end)
after the value of
Should be fixed now.
Thanks for correcting my mistake.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
These days flyspell-auto-correct-word seems to always take three
invocations to correct a word. First always giving two dumbo choices
similar to this sequence:
0. accross
1. ac cross
2. ac-cross
3. across
The choices are provided by ispell / aspell, flyspell can't do much
about that.
In wdired I can replace the space before the filenames during
query-replace with a character. It doesn't seem to cause anything,
it just doesn't look good.
I think it's a bug:
The only editable texts in a WDired buffer are filenames,
symbolic link targets, and filenames permission.
Please
The patch at
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01071.html no
longer applies cleanly to the wdired.el in CVS, even after correcting
the wrapping of long lines and ignoring white space. The patch is
also really quite large.
It is large because it also tries to handle
I see this too a lot, even in plain C files. A backtrace when this
happen looks like this:
Debugger entered--Lisp error: (scan-error Containing expression ends
prematurely 107612 107612)
scan-lists(107699 -1 0)
forward-list(-1)
backward-list(1)
beginning-of-defun-raw(nil)
Here's a tentative fix for the bug, not that well tested, but tested a
little bit:
2006-12-04 Alan Mackenzie [EMAIL PROTECTED]
* emacs-lisp/lisp.el (beginning-of-defun-raw): In the seeking a
non-nested open-paren case, check there are enough lists to move
over. Return the
6. In any case, the new behavior should be documented since it applies
whenever `open-paren-in-column-0-is-defun-start' is set to nil.
Where are documentation changes are needed for this?
In the Elisp description of `beginning-of-defun' I presume. I'd explain
the following issues:
Evening, Martin!
Evening, Alan!
1. You don't widen the buffer before calling `syntax-ppss'.
You mean I don't have to, and would get the same result without
widening? I need to widen anyway, in case point is inside a
comment/string and (point-min) is after the c/s's start.
No, I mean you
One problem I found is that it allows me to edit the last space in the
- string that indicates a symbolic link.
If I have a symbolic link a - b in the directory I'm editing, I can
delete the 2nd space, leaving a -b, and when I hit C-c C-c, I end
up with a - /dev/null.
These doc strings don't describe the position of the variable well:
The variable-at-point doc string mentions nothing about using a
variable near point - it says only around point, which suggests that
only a variable at point is used. The find-variable doc string
mentions using a variable
I disagree in general. What I agree to is that programmers should avoid
putting things that look like defuns inside comments and strings.
Commented-out code may look like a defun.
I.e. in Lisp, an open-paren-in-col0 is indeed a bad idea. In C it's not
a problem (maybe an
BTW, in Elisp an open bracket in column zero of a string should not
confuse Emacs. Yet you highlight it with `font-lock-warning-face'.
Indeed, it *shouldn't*, but it does confuse Emacs, which is why it's
highlighted ;-(. We should fix it so it doesn't confuse Emacs any more (and
doesn't
emacs -Q
M-x customize some-group
The options and faces should be in alphabetical order. The actual
order seems random.
Should be possible:
(defcustom custom-browse-sort-alphabetically nil
If non-nil, sort members of each customization group alphabetically.
:type 'boolean
:group
When a value menu is present, the current value should be on a
separate line from the Value Menu button. Currently, the current value
is listed next to the Value Menu button, which makes the Customize
buffer far too wide.
The author of an option is responsible for its appearance.
Tags for
Thx - I wasn't aware of those.
However:
- They are apparently not autoloaded, so `C-h v' doesn't recognize them
until customize has been loaded.
How can `C-h v' help you to find something you're not aware of?
- None are mentioned in the Emacs manual (or the Elisp manual, for that
When a value menu is present, the current value should be on a
separate line from the Value Menu button. Currently, the current value
is listed next to the Value Menu button, which makes the Customize
buffer far too wide.
The author of an option is responsible for its appearance.
Uh,
Usually with :entry-format and :format.
No special formatting should be necessary, just to be able to use a simple
tag. I don't believe that was why :*format were introduced.
You would have to specify what a simple tag is in the first place.
Formatting tags is for handling non-standard cases
So? Bug reports about customization don't concern such users, so ignore them
in the present context. If you don't care about customization either, then
perhaps someone else should respond to this bug report. I do care about
customization, and that's why I reported the bug.
Sorry. I herewith
flyspell-buffer runs much longer than flyspell-region, except for
regions 1,$ (line 1 to EOF) and 2,$ whereupon I also have to kill it
with ^G. Region 3,$ is OK.
$ wget http://jidanni.org/abj/articles/20061230.html
$ LC_ALL=C LANG=C emacs -Q 20061230.html
flyspell-buffer
emacs-snapshot
There's something screwy about word boundries in wdired mode. Say I
have the following files in a directory:
FOO.EXT
BAR.EXT
BAZ.EXT
If I try to downcase them by placing point on F and hitting M-l a
number of times, then I end up with this:
foo.ext
BAR.ext
BAZ.ext
The first two
This does indeed fix it. I suggest it be installed even if it's
somewhat suboptimal.
I still have to learn how to install patches.
Anyway, if people think that this patch is sufficient, the doc strings
and manual entries for `downcase-word', `upcase-word', `capitalize-word'
should explain
In Emacs 22 evaluate:
(setq myvar '((0) (1) (2) (3) (4) (5) (6) (7) (8) (9)))
(make-local-variable 'myvar)
(setq myvar 1)
then do C-h v myvar RET.
Help buffer output:
[...]
Note the local value of 1 is not shown.
Would the below break anything else?
*** help-fns.el.~1.94.~ Sun Dec
1 - 100 of 162 matches
Mail list logo
