Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.
Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.
Please describe exactly what actions triggered the bug
and the precise symptoms of
Chong Yidong [EMAIL PROTECTED] writes:
Richard Stallman [EMAIL PROTECTED] writes:
Here is an idea. When a face attribute is set by customization,
set a flag to record that fact. That flag will cause the X resource
to be ignored for that attribute.
Do you agree that is feasible?
Richard Stallman [EMAIL PROTECTED] writes:
I don't see why the insertion of the initial scratch message should be
conditional on which buffer happens to be current at that point in the
start-up sequence.
It makes sense to me. If your init file sets up other buffers, Emacs
On 2007-03-11, Chong Yidong said:
Chong Yidong [EMAIL PROTECTED] writes:
Richard Stallman [EMAIL PROTECTED] writes:
Here is an idea. When a face attribute is set by customization,
set a flag to record that fact. That flag will cause the X resource
to be ignored for that attribute.
Hello!
When I try to open a previously saved *compilation* buffer, GNU Emacs
complains about an unsafe variable, default-directory. Is this needed?
The local variables list in Kompilation-doc
contains values that may not be safe (*).
Do you want to apply it?
Leo [EMAIL PROTECTED] writes:
BTW, does that mean this change is redundant?
2007-02-06 Chong Yidong [EMAIL PROTECTED]
* faces.el (face-set-after-frame-default): Compile attributes to
be set by frame parameters before merging in X resources.
I don't think so.
Richard Stallman [EMAIL PROTECTED] writes:
The behavior where X resources override Custom (and all other Elisp
face settings) seems to have been around since forever --- it can be
seen in Emacs 21 ...
So we obviously don't need to anything about it before the release.
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?
Here is an idea. When a face attribute is set by customization,
set a flag to record that fact. That flag will cause the X resource
to be ignored for that attribute.
Do you agree that is feasible? Can you implement it?
Like I mentioned, customized faces have a
Indeed. That it doesn't interrupt isearch is not a surprise: isearch is
implemented quite differently. emacsclient interrupts recursive edits and
minibuffers,
When you say interrupts, what precisely does that mean?
Does that mean it does its job while you're in the minibuffer?
Or
When I try to open a previously saved *compilation* buffer, GNU Emacs
complains about an unsafe variable, default-directory. Is this needed?
The local variables list in Kompilation-doc
contains values that may not be safe (*).
Do you want to apply it? You can type
On Sun, 11 Mar 2007 17:35:48 +0100 Peter Dyballa wrote:
Hello!
When I try to open a previously saved *compilation* buffer, GNU
Emacs complains about an unsafe variable, default-directory. Is this
needed?
The local variables list in Kompilation-doc
contains values that may not
On 3/11/07, Richard Stallman [EMAIL PROTECTED] wrote:
Use of Emacsclient should not interfere with an isearch!
Why not? Emacsclient usually interrupts what Emacs is doing (try doing
sleep 5; emacsclient myfile.txt from a shell while you work on
Emacs).
Certainly, emacsclient terminating the
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
Stefan Monnier [EMAIL PROTECTED] writes:
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
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 move? A click.
For a click you have to find a POS-OR-AREA:
This is the buffer position of the character clicked on in the text
On 3/11/07, Juanma Barranquero [EMAIL PROTECTED] wrote:
The patch below seems to work
This is a slightly better variant of the previous patch.
Comments?
Juanma
Index: lisp/server.el
===
RCS file:
I fixed the bug with slightly different code. Thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Actually this is not what this is about. There seems to be a confusion
with the splash screen. The point here is that the *scratch* buffer is
empty. (Where it is in the buffer list does not matter.) You could
argue that there is no point in a *scratch* buffer, if desktop
default-directory is safe, right? So let's mark it as safe.
Does anyone object?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Richard Stallman wrote:
I agree that there is no reason not to put the usual scratch buffer
message into the scratch buffer. So I guess this change should be made.
Glenn, would you please install your startup.el patch?
done
___
Just curious, could one exploit this + tramp to find out if someone
has opened a file with Emacs?
Maybe one can, but I don't think we want to consider all file name
variables to be unsafe.
___
emacs-pretest-bug mailing list
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 want
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 move? A click.
That surprises me. Does anyone else agree?
Does anyone disagree?
What about the case where the
Stefan Monnier asked me if I had used hl-line-mode in the occur buffers.
I think Juri got what I meant: I think the corresponding location in
the source buffer is not marked enough. A behaviour like grep where
there location is temporarily highlighted is nice. (But there you end
up in the source
28 matches
Mail list logo
