I'm not sure what's the best solution, but in any case I think that
read-from-minibuffer shouldn't fail just because its prompt argument is
read-only. So I suggest the patch below.
I think this patch is ok.
I'm still not comfortable with re-installing the change to isearch at
this time
So with the patch, we get text is read-only errors, and without the
patch we get some messages without the minibuffer-prompt-properties.
One possibility is to copy minibuffer-prompt-properties,
delete the read-only property, and install the rest.
With my patch to minibuf.c, we
Debugger entered--Lisp error: (text-read-only)
read-from-minibuffer(#(Search: 0 8 (read-only t face
minibuffer-prompt))...
byte-code(...
isearch-edit-string()
isearch-exit()
call-interactively(isearch-exit)
This seems to indicate a bug elsewhere.
This backtrace is not enough to pin it
One possibility is to copy minibuffer-prompt-properties,
delete the read-only property, and install the rest.
With my patch to minibuf.c, we wouldn't need to do that.
How is that?
Because it should now work just as well with the read-only property.
Stefan
I see what you mean. On the other hand, it is right that M-f skips
over can't as one word. Each choice is right in some cases and
wrong in others. Changing from one to the other would be a mistake.
Maybe someday someone will figure out a solution to DTRT in all the cases.
We already
Another solution is to ask the maintainers of that window manager
(metacity?) to turn off that feature for mode-line. Can you tell me
how to write to them?
Or maybe they'd be willing to improve the feature so that it also sets the
mode-line-inactive face.
Stefan
The change also broke editing of the isearch string.
I don't think is fixed by the C-level fix.
I'd be surprised if my fix doesn't address this problem as well.
Stefan
PS: But I like surprises.
___
emacs-pretest-bug mailing list
Enter the below text into a vanilla buffer. It consists of a rather
long expression (3415 characters, I believe), which is all in one
line (rather than nicely formatted). Add a few extra lines to the
expression.
That is not a precise specification. I tried this, and it worked
fine, but I
Or perhaps no change is needed. If you resume a saved session, you
have presumably seen the scratch screen in the previous session.
So maybe it is right that it goes straight back to the status that was
saved, without showing the scratch screen again.
I'd agree with that. I think `desktop'
I think #4 should be fixed. I am not sure #5 is a bug.
It is true that the mouse has not moved physically, but in
some virtual sense it has moved due to the scrolling.
In this case, the scrolling was a bug. But suppose there had
been scrolling for a valid reason. Wouldn't it be correct
Now I try to use emacsclient to open something else, but since isearch
is running the new buffer does not appear on top.
Hmm... indeed, I can reproduce it. Not sure why, yet.
emacsclient seems to interrupt find-file, swith-to-buffer and areas
marked to be copied, so I think it is somewhat
Wouldn't it be a good idea to highlight the occurrence, at least
temporarily, instead of just putting the not-so-easily-seen point on
it?
Have you tried hl-line-mode in occur buffers?
Stefan
___
emacs-pretest-bug mailing list
* default-directory : ~/Quellen/X11R7.1/
I'm not sure what's the reason to put such a file-local variable.
More to the point, I'm not sure it's a good idea in the first place.
Stefan
___
emacs-pretest-bug mailing list
I can't think of any case where I'd expect Emacs to think I did a drag
when I didn't physically move the mouse, really.
What do you think it should do in such a case,
where scrolling happens validly and correctly
(and you expected it)
while mouse-1 is held down?
If mouse did not
+ (condition-case nil
+ ;; If we're running isearch, we must abort it to allow Emacs to
+ ;; display the buffer and switch to it.
+ (mapc #'(lambda (buffer)
+ (with-current-buffer buffer
+ (when (bound-and-true-p isearch-mode)
+
I'm not sure what's the reason to put such a file-local variable.
More to the point, I'm not sure it's a good idea in the first place.
The reason M-x compile generates this local variable is to make sure
the error messages are interpreted with respect to the proper
directory.
We
If mouse did not move? A click.
That surprises me. Does anyone else agree?
Does anyone disagree?
I think it would be a drag, for example in cases where the mouse wheel is
used to scroll while mouse-1 is held down,
Good point: if there's some other mouse action in the mean time, it
What about the case where the user moves the mouse around substantially
but brings it back to the same place (although it's over a different
character, so he can't tell it's the same)?
This used to result in a click in Emacs-21, and I've changed it to a drag in
Emacs-22.
Stefan
PS:
I don't think we will be able to find a patch that can break out of isearch
for Emacs-22 (it's probably going to be too big a change). But the fact
that not only it doesn't break out of isearch, but additionally the buffer
isn't displayed at all looks more serious.
The patch below seems to
Yes, we can add some ad-hoc isearch hack in server.el for it.
It's kind of ugly, tho.
No doubt. Having server.el forcefully exit from recursive edits and
abort isearches is inellegant.
I don't think the behavior is inelegant (it's not great, but there's not
much we can do without major
Yeah, well. The thing is, what do we do now wrt the isearch problem?
I can't answer that before I've figured out what is the reason that the
buffer is not displayed.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Presumably if it's saved, it'll be saved in that same directory, so
it'll work just as well without the default-directory
file-local variable.
The user could save it anywhere. He might not want to save it
in the directory with the source files.
Indeed, but it's hardly specific
I cannot think of a case where scrolling would be legitimate and expected
when there is just a short click with no movement or other events in
between mouse-1-down and mouse-1-up.
I can: current-buffer is just constantly scrolling (it's watching an
active log file, or it's a game, or
I think it's due to this change
2006-07-18 Stefan Monnier [EMAIL PROTECTED]
* progmodes/compile.el (compilation-find-file): Handle the
cases where the user selects a non-existent file.
Indeed.
Does the patch below restore the old behaviour for you?
I think reverting
ISTR that I added this because I ran into problems without it.
I think this should be a personal user hack, not a default for Emacs.
No, the problem is not special to me or my usage.
Wha makes you so sure?
Stefan
___
emacs-pretest-bug
For me it's much more common to access the same file under different names
(typically via sshfs or Tramp, but also depending on if I'm on the server
or on an NFS client, ...). And I always get surprised that even though
I was careful to save the file where it belongs,
I guess the jury is still out on this one. I don't think there's
a right answer in general for this case, it depends on the specifics.
But at least if the click is short, I'd expect it to be a click.
If it lasts long, I'd probably expect it to be a drag. If it's in the
+ (condition-case nil
+ ;; If we're running isearch, we must abort it to allow Emacs to
+ ;; display the buffer and switch to it.
+ (mapc #'(lambda (buffer)
+(with-current-buffer buffer
+ (when (bound-and-true-p isearch-mode)
+
Why not do this as with `isearch-allow-scroll' t? I don't know
server.el, maybe something flashy like ...
Yuck.
(cond
((minibufferp))
((buffer-local-value 'isearch-mode (current-buffer))
(let ((isearch-point (point))
(new-window (split-window)))
;; ... do the
A minor mode defined by define-minor-mode does not get added to the
customization group given. To show this evaluate this code:
(define-minor-mode the-temp-mode nil
doc string
:group 'the-temp-group)
What would you want to be added to the group?
This only defines a buffer-local variable
In contrast, %! is far too generic to be useful. It may be a
heuristic for a PostScript interpreter to decide whether it is getting
fed PostScript on stdin. But it does not sound like a useful
heuristic for a text editor to decide whether a named file contains
PostScript code or anything
/21/07, Stefan Monnier [EMAIL PROTECTED] wrote:
Who put this entry in magic-mode-alist, and why?
It's there since the beginning, at least according to ViewCVS
(files.el, revision 1.720) and lisp/ChangeLog.11:
2004-11-03 Daniel Pfeiffer [EMAIL PROTECTED]
* files.el (xml-based-modes
This part of revision 1.53, complete.el, was undone by revision 1.54,
but the removal wasn't mentioned in the log. Was this intentional?
It was most likely an oversight of Eli when he installed the
next patch. Thanks for spotting it, I've re-installed the patch.
Stefan
This part of revision 1.53, complete.el, was undone by revision 1.54,
but the removal wasn't mentioned in the log. Was this intentional?
It was most likely an oversight of Eli when he installed the
next patch.
What oversight? what next patch? Please provide some minimal details.
Check
in 22.0.96 after compiling with
./configure --with-gtk
on Slackware 10.2 and Debian Woody:
The scrollbar resizes while typing more characters to a line.
Yes, indeed, it does.
I mean that I get more space to scroll around, when a line gets longer.
I'm not sure I understand, but it
I'm writing a new mode for Emacs that involves a massive
regular expression, auto-generated from a list of files in
the directory. If the number of files is too large (c. 1500,
depending on the length of the filenames), then the regular
expression that gets built is too big, and Emacs flashes
If we're talking about the proverbial Emacs newbie, there are few
things more confusing than wiping out the toolbar (Where did the
buttons go?).
The fact that the text editor, the info browser and the news reader all use
the same Emacs virtual machine doesn't imply they should use the
same
do you remember why you put an entry
(%![^V] . ps-mode)
in magic-mode-alist? Did it just seem like a good idea or was there
some particular (set of) circumstances you had bumped into that called
for it?
I don't remember, but I checked this: The way I read magic, a conforming
[ Added meaningful subject and redirected to appropriate mailing-list.
Alin, please be careful about those things. Using M-x report-emacs-bug
takes care of the second point and is generally recommended.
I also added bug-cc-mode in Cc. ]
I report again, becuase this bug was ignored. I
Thank you for your response. It was helpful to know that this isn't going
to be an easy fix. We're already using regexp-opt, which is supposed to
optimize and shrink the regex.
In that case I don't think there's much you can do (you may be able to
tweak regexp-opt to reduce the compiled
This seems to be a limitation of the venerable mkinstalldirs program.
I wonder how other projects handle this problem?
We could replace the mkinstalldirs in Emacs with one from a recent
automake, which seems to have addressed this issue. But I think that
trying to use paths with spaces will
Thanks, Stefan. That makes sense. But it would need to run within the
fontification function, so we'd like it to be speedy...
Try it. It's not at all obvious to me that performance will be a problem.
I'm often surprised at how much work one can do within font-lock without it
having any
The variable above is marked as obsolete but used in font-core.el.
Should it be that way?
Of course. If it wasn't used at all, it wouldn't be obsolete but
removed.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
The variable above is marked as obsolete but used in font-core.el. Should
it be that way?
Obviously even obsolete variables have to be used _somewhere_, else
they are not just obsolete but totally useless. Can you elaborate on
your question?
The variable is marked obsolete in the same
emacs -Q +132 .../emacs/src/lisp.h
Inserting space + undoing will sort it out, so it might be triggered
by the chunking done by jit-lock.
Increasing jit-lock-chunk-size to 2000 makes this fontification glitch
go away.
You mean it solves this instance of the glitch. It will still occur in
|In jidanni-header-author:
|.emacs:249:11:Warning: reference to free variable `header-prefix-string'
|.emacs:282:29:Warning: assignment to free variable `comint-input-autoexpand'
However the first error is in jidanni-header-author, but the second
isn't, so bytecomp.el should insert a blank
Cannot open load file: term/mac-win
[...]
This error obviously occurs before loading any user-specific settings, so
I'm not sending the Emacs debug log.
Actually, this is not obvious at all to me. AFAIK the term-specific setup
file (such as term/xterm or term/x-win or term/mac-win) is loaded
Emacs infloops when I press the key at the end of this line (to the right of
the last '(':
matching_dbs = commands.getoutput(cat
//xx/x/x.xxx | grep ^%s | grep -v xxx %
region).strip().split(
I assume this is using Emacs's own python.el, not python-mode.el,
+ /* At this moment, we still don't know how to decode the directory
+ name. So, we keep the bytes in multibyte form so that
+ ENCODE_FILE correctly gets the original bytes. */
Vdata_directory
! = Ffile_name_as_directory (string_to_multibyte
!
Emacs 23 surely returns nil in that case. I think the
behaviour of Emacs 22 is a bug (or at least very confusing).
I don't think it's that important and both sides have fierce proponents
(just like the ()-vs-#t in the Lisp/Scheme community, and probably
comparable to the little/big-endian
iff stands for if and only if but maybe
Return non-nil if and only if we received output before the timeout expired.
would be more comprehensible.
The iff idiom is sufficiently common that we don't want to shy away
from it just at this one place. So either we rule it out everywhere, or we
use
The iff idiom is sufficiently common that we don't want to shy
away from it just at this one place. So either we rule it out
everywhere, or we use it liberally.
Sufficiently common in Emacs (~ 600 instances); I've never seen it
anywhere else as far as I remember.
AFAIK it's pretty standard
Symbols are indeed on the heap, and in fact it's quite possible to have
two identically named symbols which aren't eq. However in normal usage
symbols are interned when they are read, which makes them eq.
A more common (but still not very common either) term for interned is
hash-cons'd.
Here is the code that does this:
(define-key org-mode-map [menu-bar headings] 'undefined)
(define-key org-mode-map [menu-bar hide] 'undefined)
(define-key org-mode-map [menu-bar show] 'undefined))
If org-mode-map inherits from outline-mode-map, then it should be OK,
although binding them to
selecting a keymap (e.g. when changing minor-mode, creating 'keymap
overlays, setting overriding-local-map, use-local-map) in a
run-with-timer or run-with-idle-timer event doesn't take immediate
effect.
Consider the following example:
(run-with-timer 3 nil '(lambda ()
But isn't globalbind already a copy of the global map?
Nope.
I see no function assq-remove-all. Is this in Emacs 23?
My guess is, it's (another) one of Stefan's local changes... :)
No. I don't have such a thing here either. But the name should make the
intended behavior clear enough.
I have run into some code that was setting perl-indent-level and
cperl-indent-level as local variables. Should I mark them as safe?
Other modes do the same for similar variables.
Yes, please,
Stefan
___
emacs-pretest-bug mailing list
A note: What makes me a bit upset is more that I get the feeling that you
think the bug is unimportant
Actually, I do think so: the position where the cursor is displayed when
placed on a before-string (or a display string) has always been
fairly approximate. E.g. Whether to display it
I see in fill-move-to-break-point that fill-nobreak-predicate is
ignored (let bound to nil) if there's no breaks found before
fill-column. It seems to me not a good idea to sometimes obey that
var and sometimes not. The docstring seems pretty definite when it
says If it returns t, fill
I don't know anything about the Emacs code, but CMU CS had a networked
filesystem (the mach/spice project vaxes) which had the concept of a
super-root above /, accessed via /... E.g. to access file /x/y on
machine blargh, you'd use /../blargh/x/y (IIRC, /.. was a real
Would you please install your patch?
Done,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is risky (is it?).
Font-lock can modify arbitrary text properties, such as display
strings, and not just faces.
And it can also directly run any code, which is even more immediately
I suggest not changing this until we have time to discuss this,
i.e. after the release. It would not be good to introduce a security
risk into Emacs at the 11th hour.
Obviously. I didn't even byte-compile the code (let alone run it).
Stefan
In my recent cvs build, visiting the api.html file below selects
xml-mode, where I hoped to get html-mode (or the xhtml variant
thingie).
Agreed, and the file contents shouldn't make any difference in this respect
since the file's extension is explicit.
Stefan
I think a regexp matching anything except a given set of literals can be
built mechanically (does someone have something to do that?).
In theory, yes, but IIRC the resulting regexp may be of a size exponential
w.r.t the size of the literals ;-(
I believe in practice it's not going to be
In a recent build of the cvs, visiting the file minimal.html below
selects sgml-mode, where I hoped to get html-mode. According to the
Again, the best fix seems to be to make sure the .html extension
is heeded.
Stefan
___
Agreed, and the file contents shouldn't make any difference in this
respect since the file's extension is explicit.
But they do, since magic-mode-alist describes itself as overriding
auto-mode-alist. Maybe you mean this is a Bad Thing?
The should was not meant to describe what *does* happen,
Maybe if magic-mode-alist were combined into auto-mode-alist it'd be
easier to control conflicts or precedence among content vs filename
tests. (Not that you want to get too fancy about such things ...)
Agreed.
Stefan
___
The attached file is valid XHTML 1.1 but indents badly because of the inte
?php ... ? part. I paste it here for simplicity too:
Hmm... does the patch below fix it for you?
If you put a ? inside your PHP code, it seems it would still be valid
XML, but indentation will probably get confused.
Calling `up-list' inside a string gives this error:
up-list: Scan error: Unbalanced parentheses, 14, 19
Actually, it can give all kinds of different errors as well as
desriable behaviors.
This is obviously not the case in this example:
(setq foo bar)
^ point
I can't tell if
The attached file is valid XHTML 1.1 but indents badly because of the
inte
?php ... ? part. I paste it here for simplicity too:
Hmm... does the patch below fix it for you?
If you put a ? inside your PHP code, it seems it would still be valid
XML, but indentation will probably get confused.
Can you show us which changes to python.el we need to remove?
Or identify them by which versions they were checked in in?
Not easily in detail. Anything I actually contributed I consider OK,
obviously. I.e., I'd remove anything just taken from the version on
my web site.
While I can
However, 1.40 (2006-08-20) by you is extensive and the changelog says
Update to Dave Love's latest version. Was this directly from him?
Ahh... I guess my memory failed. We should revert this change, then.
The rest looks good,
Stefan
___
C-x d /tmp RET
M-! touch 00a RET
g -- Now yu should see a file named 00a
C-x C-q
undo -- Now you don't see the file 00a any more
The operation undone was the deletion of the old buffer contents and
insertion of the new contents. No wonder I turned off undo for that.
However, 1.40 (2006-08-20) by you is extensive and the changelog says
Update to Dave Love's latest version. Was this directly from him?
Ahh... I guess my memory failed. We should revert this change, then.
Could you do this?
I'm short on time these days, so I'll at least wait until Richard
Here's a variant:
(defun regexp-not-in (words endchars optional prefix)
Return a regexp that matches anything other than words in WORDS.
ENDCHARS is a list containing the chars that can appear after a word.
;; `prefix' is only used internally.
(if prefix (setq words
+ ;; Do let Ctl and Meta chars expand if they try.
+ (not (event-modifiers last-command-char))
+ (equal this-command 'self-insert)
Why check (not (event-modifiers last-command-char)), then?
Stefan
The following strikes me as strange:
(key-binding €) ;; (Euro character) returns 'self-insert-command, but
(key-binding £) ;; (Pound character) returns nil
Is this a bug?
Depends. First and foremost it depends on what are € and £, since there
are many different such values, all displayed
(t 342604 self-insert-command)
[...]
(t 2211 nil)
or generically: (key-binding (vector (string-to-char £)) t) -
self-insert-command
(key-binding £ t) - nil
So, it seems to be a problem with the string specification of the key.
Oh, it rings a bell: IIRC key-sequences specified as strings
- if (INTEGERP (c) XINT (c) 0x80 STRINGP (key))
+ if (STRINGP (key) XINT (c) 0x8 !STRING_MULTIBYTE (key))
Shouldn't that be 0x80 ?
Is that a trick question? I see Andreas fix it already.
Stefan
___
emacs-pretest-bug
Why not just keep it in unibyte form?
Because the current ENCODE_FILE seems to assume that file name strings
are in multibyte or ASCII-only unibyte. Also, the initialization of
current_buffer-directory in init_buffer (buffer.c) does the same
thing.
If we allow non-ASCII unibyte strings
Running emacs in terminal 'urxvt'¹, I seem to lose F11 and F12
keys. For example F11 behaves the same as F1 and F12 as F2. Is this a
known problem?
Does Emacs use lisp/term/rxvt.el in your case? If so, please see
there for a comment around line 95 that talks about this issue.
Does [S-f1]
Then we have to be careful about the place to use DECODE_FILE, because
it may cause GC, and the comment around the recursive call of
Fexpand_file_name also applies to this situation.
Indeed.
Stefan
___
emacs-pretest-bug mailing list
In the sense, `S-f1' and `f1' that they invoke the same function.
That's OK: it's only because there's nothing bound explicitly to S-f1, so
Emacs defaults to using the binding of f1. Handy when you use caps-lock.
However, I check the lossage and S+f1 is the same as f11.
Thanks,
1. Open a html file. Notice we are in html-mode now.
2. Hit C-c C-t to create a new html tag. Enter ``a'' to create an
anchor tag.
3. We are now prompted for an attribute. Enter ``name'' to create
named anchor.
4. Notice we are not prompted for a value for the ``name'' attribute.
Emacs
Perhaps a change in the code (emacs 21 was indent-to-left-margin),
which didn't make it to the manual.
That seems to be a change made by Stephan.
Stephan, what was the reason for that change?
If you mean me, then yes, I made that change. All Emacs modes use
indent-relative or some
think it needs time to be tested widely. I'm not well informed
about RFC2822 and what mail-extr.el does (especially the voodoo
operation, which is disabled by default for Japanese names), too.
RFC2822 only talks about the transmission-format, which is made of bytes,
not chars. It's probably
From textmodes/sgml-mode.el:
If you like upcased tags, put (setq sgml-transformation-function 'upcase)
in your `.emacs' file.
To reproduce the problem:
emacs -Q
C-x C-f a.html RET
M-x set-variable RET sgml-transformation-function RET upcase RET
C-c C-t
Then find some files beginning with m and n. Now do
M-x iswitchb-mode
C-x b m
For me that matches both buffers beginning with m and n.
IIRC by default iswitchb uses substring matching, so any file that has an
m somewhere in its name will match.
Stefan
However there is one thing I do not understand and that other people have
asked: If one want to use functions from cl.el (not only macros), how does
one do then? Is (eval-when-compile (require 'cl)) sufficient then?
Solution 1: you don't!
Solution 2: you make sure that your call to the CL
In my recent cvs build, visiting the api.html file below selects
xml-mode, where I hoped to get html-mode (or the xhtml variant
thingie).
I believe this is now fixed because the .html extension should now
take precedence. Can you confirm?
Stefan
Nikolaj == Nikolaj Schumacher [EMAIL PROTECTED] writes:
Hello,
`canonically-space-region' doesn't stop at the end of the region.
That's because it limits its searches at `end', while the actual region
keeps getting smaller.
I've installed the patch below to fix this problem.
Interpreting this is milliseconds, it follows that after 74 hours, 33
minutes and 55 seconds I will start getting the error :(
Hmm.. the code needs the integer to wrap-around, but truncate refuses to
do that.
Does the patch below work?
Stefan
--- xt-mouse.el 16 mai 2007 11:59:29
Interpreting this is milliseconds, it follows that after 74 hours, 33
minutes and 55 seconds I will start getting the error :(
Hmm.. the code needs the integer to wrap-around, but truncate refuses to
do that.
Does the patch below work?
Fixed my 8 days old Emacs in mid-flight, I am
Would someone please install this in Emacs 22 also?
Done,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Would someone please install this fix in Emacs 22?
Done,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I think it would help to add an explicit statement that you can place
point between groups (which are defined as consecutive characters with
the same `intangible' value). That is, clarify that you can place
point between groups, but not within a group.
I clarified that.
I forgot to answer this previously, sorry. I summarise.
I had this in my local variables section:
mode: font-lock
font-lock-keywords: (^\\S-.*:$)
which worked in Emacs 21, but does not work any more in Emacs 22. I
solved the problem by writing instead:
mode: font-lock
Only thing I say, if it is left as it is, maybe it should be mentioned
in the NEWS with something like:
Font-lock-keywords can not be set any more in the local variables
section of a file. Use font-lock-defaults instead.
I find the change in behavior sufficiently mysterious that I'm not
(set (make-local-variable 'font-lock-keywords)
! (font-lock-eval-keywords (or keywords font-lock-keywords)))
Wouldn't this mean that old keywords survive a major-mode change?
What about the companions in `font-lock-defaults'? In general I
think all those should survive iff they have
601 - 700 of 725 matches
Mail list logo
