> I'm not convinced this change is a good one. What if your macro
> involves a call-process call to an external program that interacts
> with Emacs via the keyboard?
clipboard, of course, not keyboard.
That must be very rare--are there any programs that could be invoked
this way
Thanks for posting the URL, though it seems that the web interface at
lists.gnu.org eats multiple spaces. Here is the Gmane URL for the
original post from Kevin Rodgers with correct indentation:
http://article.gmane.org/gmane.emacs.devel/33146
Can someone please install it?
> From: "emacs user" <[EMAIL PROTECTED]>
> Bcc:
> Date: Tue, 16 Aug 2005 04:47:39 -0400
> Cc: cygwin@cygwin.com, [EMAIL PROTECTED], [EMAIL PROTECTED],
> emacs-devel@gnu.org
>
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging w
>From my previous message:
"Inviolable" is just an internal Custom tag.
Well, that was a little bit misformulated. It is not "internal",
because it appears user-visibly in the Custom buffer. What I meant
with "internal to Custom" is that it is strictly a Custom thing, and
meaningless in as f
Drew Adams wrote:
- Neither the Emacs manual nor the Emacs-Lisp manual contains the word
"inviolable".
"Inviolable" is just an internal Custom tag. From cus-start.el:
(const :tag "Inviolable"
:doc "Prevent point from ever entering prompt"
:format "%t%n%h"
:in
I'd still be interested in knowing what your text-copying
use case is.
I sometimes use command history to turn an interactive command into a
piece of lisp code to use later, or at least study how it was invoked,
or reinvoke it on a variable instead of a literal string.
Sor
> "Drew" == Drew Adams <[EMAIL PROTECTED]> writes:
Drew> I'd still be interested in knowing what your text-copying
Drew> use case is.
Drew> I sometimes use command history to turn an interactive command into a
Drew> piece of lisp code to use later, or at least study how it
On a related subject, and being a bit nit-picky - does anyone else think
that these things should be harmonized & better documented?
- Neither the Emacs manual nor the Emacs-Lisp manual contains the word
"inviolable".
- Both manuals refer to the "intangible" property.
- Is "intangible" not th
Well, now that I'm clear on the rest of the thread, I realize I'm
talking about a different part. No, I've never moved dot into
the prompt.
OK. Thanks for clearing it up.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.g
Here is one crack, the 48x48 version and a 16x16 version. BTW if anyone
want to play with this some of the Gimp xcf files are at the same
directory as the images for the web page.
This is pretty good, but the E is a little fuzzy. Perhaps a
small change in color or drawing style coul
Richard M. Stallman wrote:
BTW the message "Text is readonly" is also confusing when "Inviolable"
is set.
I do not understand.
You expect the prompt to be readonly and the message is
disturbing when you delete character by character and then suddenly this
text appears over t
Lennart Borgman wrote:
As a notorious shell user I of course started to see if up and down
arrows could be used for command recall.
Just the up and down arrows could not work, because in Shell mode, you
are supposed to be able to move through the buffer, so the arrows need
to have their us
Luc Teirlinck wrote:
Lennart Borgman wrote:
As a notorious shell user I of course started to see if up and down
arrows could be used for command recall.
Just the up and down arrows could not work, because in Shell mode, you
are supposed to be able to move through the buffer, so the arrow
Luc Teirlinck wrote:
Lennart Borgman wrote:
Which is a big difference compared to shell buffers where you can erase
the prompt. That too was a surprise to me in the beginning.
You can change that by by setting comint-prompt-read-only to t.
But erasing prompts is sometimes useful for clea
"Stuart D. Herring" <[EMAIL PROTECTED]> writes:
> Moreover, this whole change would be optional (customizable), so the
> user of any such macro could turn off that option
OK. I don't expect my hypothetical case will come up often, but it is
possible. I just wanted to make sure that simply binding
On 16 Aug 2005, at 18:57, Luc Teirlinck wrote:
David Reitter wrote:
(I delete text pretty often that's in the minibuffer, and then I
accidentally get into the prompt), so I set 'read-only' (similar to
inviolable, i guess) as a default in Aquamacs.
No, read-only prevents you from erasi
Michael Welsh Duggan writes:
> I wish I could say just when this problem cropped up, but...
>
> In the current CVS, I cannot run gdb though the gud on two seperate
> programs simultanously. For example, if I start a gud session for
> program A, then one for program B, if I then type "b main"
I wish I could say just when this problem cropped up, but...
In the current CVS, I cannot run gdb though the gud on two seperate
programs simultanously. For example, if I start a gud session for
program A, then one for program B, if I then type "b main" in program
A's gud buffer, the breakpoint g
Is it ok to install a change that implements support for Aspell filters
to ispell.el now? I can send a small patch that implements this.
Please do.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-de
It is useful to move point into the minibuffer prompt without
changing default settings. But since this can be confusing for
beginners, maybe it should be more difficult to move point into the
prompt area by default? For example, to disable moving point into
the prompt with C-
% Copyright (C) 1997, 2002, 2003, 2004, 2005 FSF, Inc.
...
\def\year{2005}
the rationale is that for reference cards and such, a big (and
ever-increasing) list of years is unnecessary clutter.
what do you think of this (idea A)?
That is ok.
___
Maybe it is possible to shrink it. I made several versions of Robs gnu
head in the size of 16x16 (together with M-x).
Please don't get diverted onto this. There is no need for a gnu head
in an Emacs icon. Its job is to say "Emacs", not "GNU".
__
BTW the message "Text is readonly" is also confusing when "Inviolable"
is set.
I do not understand.
You expect the prompt to be readonly and the message is
disturbing when you delete character by character and then suddenly this
text appears over the prompt.
I can't follo
And a question - ignore, if this has already been beaten to death -
shouldn't "inviolable" be the default value?
That seems like a good argument to me. I will try that option myself
and see what I think of it.
___
Emacs-devel mailing list
Emac
>>> @table @code
>>> @item mode-line
>>> ! @itemx modeline
>>
>> I don't know too much about Texinfo, but shouldn't there be a @code
>> modifier on both of those item labels?
>
> That's what "@table @code" is for (*note (texinfo)table::).
Ah, thanks -- I was thinking of it like \frame or so in
> "Drew" == Drew Adams <[EMAIL PROTECTED]> writes:
Drew> I'd still be interested in knowing what your text-copying use case is.
I sometimes use command history to turn an interactive command into a
piece of lisp code to use later, or at least study how it was invoked,
or reinvoke it on a vari
"Stuart D. Herring" <[EMAIL PROTECTED]> writes:
>> @table @code
>> @item mode-line
>> ! @itemx modeline
>
> I don't know too much about Texinfo, but shouldn't there be a @code
> modifier on both of those item labels?
That's what "@table @code" is for (*note (texinfo)table::).
Andreas.
--
A
> @table @code
> @item mode-line
> ! @itemx modeline
I don't know too much about Texinfo, but shouldn't there be a @code
modifier on both of those item labels?
Davis Herring
--
This product is sold by volume, not by mass. If it appears too dense or
too sparse, it is because mass-energy con
Lennart Borgman wrote:
Which is a big difference compared to shell buffers where you can erase
the prompt. That too was a surprise to me in the beginning.
You can change that by by setting comint-prompt-read-only to t.
But erasing prompts is sometimes useful for cleanup in shell buffers,
w
I think it is quite confusing that you can move the point into the
prompt area in the minibuffer. Why don't we use something like the code
below to avoid this:
If we want to make it impossible to move point into the prompt,
it should suffice to give it an intangible property of t, ri
Luc Teirlinck wrote:
David Reitter wrote:
(I delete text pretty often that's in the minibuffer, and then I
accidentally get into the prompt), so I set 'read-only' (similar to
inviolable, i guess) as a default in Aquamacs.
No, read-only prevents you from erasing the text, not from moving
David Reitter wrote:
(I delete text pretty often that's in the minibuffer, and then I
accidentally get into the prompt), so I set 'read-only' (similar to
inviolable, i guess) as a default in Aquamacs.
No, read-only prevents you from erasing the text, not from moving into it.
read-only _i
On 16 Aug 2005, at 05:51, Drew Adams wrote:
And a question - ignore, if this has already been beaten to death -
shouldn't "inviolable" be the default value? A novice might get
confused and
not know about the option to make the text inviolable;
Yes, I agree: it should be default. I used to b
Karl Chen writes:
> Kevin Rodgers posted a patch that would allow `grep' to close stdin,
> solving this annoyance, but it appears it was never followed up.
> http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg00452.html
Yes, that's exactly what David Kastrup suggested in another reply.
Th
David Kastrup writes:
> I think what rather should be done is that standard input on the
> grep process gets closed. That requires no special options, and it
> will lead to a sensible result without obscure extra options.
This seems a rather clean solution. Karl Chen pointed out that Kevin
Rodg
> I'm not convinced this change is a good one. What if your macro involves
> a call-process call to an external program that interacts with Emacs via
> the [clipboard]?
What kind of keyboard macro could communicate asynchronously with another
program, via the clipboard or otherwise? Something lik
Jason Rumney wrote:
Stuart D. Herring wrote:
I realize I never did implement this -- can I get some opinions on which
of these approaches to follow? So far my reasoning is that the
execute-kbd-macro path is simpler and cleaner, but the kill-functions
path
is more transparent (as well as havi
> I could create a patch for that by merging the text from both nodes
> into `(emacs)Standard Faces', if this is ok.
>
> Please do, and thanks for noticing the problem.
Below is a patch which merges the nodes `(elisp)Standard Faces' and
`(emacs)Standard Faces' into the latter.
Index: lisp
Stuart D. Herring wrote:
I realize I never did implement this -- can I get some opinions on which
of these approaches to follow? So far my reasoning is that the
execute-kbd-macro path is simpler and cleaner, but the kill-functions path
is more transparent (as well as having the trivial advantag
Kevin Rodgers wrote:
> > Then `kill-new', `kill-append', and `current-kill' would be modified to
> > ignore `interprogram-*-function' if `macro-private-kills' is set and a
> > keyboard macro is executing.
>
> It would be simpler to temporarily bind the interprogram-*-functions
> variables to nil
Reviving a thread from a few weeks ago:
> I noticed this because it got a warning. It seems rather a kludge.
> Is there any more general feature that could be used here?
>
> (defun ff-which-function-are-we-in ()
> "Return the name of the function whose definition/declaration point is
> in.
> Al
Here is one crack, the 48x48 version and a 16x16 version. BTW if anyone
want to play with this some of the Gimp xcf files are at the same
directory as the images for the web page.
The logo is OK, as a logo (like the Nike swoosh). If it became known to
everyone _as a logo_, then it coul
Lennart Borgman <[EMAIL PROTECTED]> writes:
> Here are some variations of Davids suggestion where I have tried to make
> the E more visible.
Those look all really nice, especially the third one.
--
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature
Drew Adams wrote:
I note too that, by design, commands like `C-a' do not move
into the prompt.
That is because of field properties. To see this, do C-x C-f,
move into the prompt (sorry) and to C-u x =
That's the how, not the why. My point was that it is desi
One possible compromise, assuming there is a useful use case
for copying prompt text, would be to permit copying it with the
mouse,
but still inhibit moving the cursor into the prompt by command
or keyboard. Would that be good enough?
That would force one to use th
Luc Teirlinck wrote:
Lennart Borgman wrote:
The current behaviour is probably not what a new user expects.
But no harm is done if you move into the prompt. Just move out of it again.
Once you noticed that you can move into the prompt, you know you can.
No docs to read to find it out.
Th
Drew Adams wrote:
> The idea of using an E on a gnu is ok semantically. Whether it looks
> better than just an E, I am not sure.
Attached is an idea ;-) It don't look too bad when resized as a 16x16
icon.
This could make an attractive _logo_, but it would _not_ work as a 16x16
icon,
Lennart Borgman wrote:
The current behaviour is probably not what a new user expects.
But no harm is done if you move into the prompt. Just move out of it again.
Once you noticed that you can move into the prompt, you know you can.
No docs to read to find it out.
I do not like any of the com
Henrik Enberg <[EMAIL PROTECTED]> writes:
>> From: Edward O'Connor <[EMAIL PROTECTED]>
>> Date: Fri, 12 Aug 2005 10:19:09 -0700
>>
>> > Edward, can you please recheck if this problem happens with "emacs -Q"?
>>
>> It still happens with emacs -q --no-site-file.
>
> FWIW, it happens for me too on
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> No, Emacs should follow the user's settings (or its own defaults)
> in the same way for all the tool kits.
I see. Since it's easily customizable from the Show/Hide menu, it's not
really a problem anyway.
> That would seem to be a bug, but I do
Drew Adams wrote:
> The idea of using an E on a gnu is ok semantically. Whether it looks
> better than just an E, I am not sure.
Attached is an idea ;-) It don't look too bad when resized as a 16x16
icon.
This could make an attractive _logo_, but it would _not_ work as a 16x16
icon,
for the etc/*.tex files, i would like to update the copyright
notice in the comments w/ the full list of years, and the
rendered copyright notice w/ 2005, only. for example:
% Copyright (C) 1997, 2002, 2003, 2004, 2005 FSF, Inc.
...
\def\year{2005}
the rationale is that for reference cards
Juri Linkov wrote:
It is useful to move point into the minibuffer prompt without
changing default settings. But since this can be confusing for
beginners, maybe it should be more difficult to move point into the
prompt area by default? For example, to disable moving point into
the prompt with
> On 2005-08-15 19:25 PDT, Richard M Stallman writes:
rms> So, my grep program supports "-H" but it apparently
rms> has not the expected semantics.
rms> That is a very vague statement. It tells us nothing.
Emilio is reiterating the same issue I raised on 2005-02-03 [1]:
>>It is useful to move point into the minibuffer prompt without
>>changing default settings. But since this can be confusing for
>>beginners, maybe it should be more difficult to move point into the
>>prompt area by default? For example, to disable moving point into
>>the prompt with C-b, but all
> The current behaviour is probably not what a new user expects.
> I can't think of any other program that behaves like this.
> Shell prompt for example do not.
>
> I agree with Drew that the default should be that "Inviolable"
> should be on (it should not be possible to move the point into the
>
Juri Linkov wrote:
The current behaviour is probably not what a new user expects.
I can't think of any other program that behaves like this.
Shell prompt for example do not.
I agree with Drew that the default should be that "Inviolable"
should be on (it should not be possible to move the point
> If the user forgets to provide a filename to "M-x grep" (as in
> "grep -nH foo") it will run indefinitely waiting for input from
> stdin until killed. In such cases it's useful to have `null-device'
> appended, even if the grep program supports the option "-H" (which
> has an other purpose anywa
> However, if you want to suggest ispell checking the manuals, I agree
> that would be useful to do. Would you like to start?
It would be tedious to confirm the correctness of every function or
variable name in .texi source files of the manual during ispell checking.
ispell supports checking only
Emilio Lopes <[EMAIL PROTECTED]> writes:
> Emilio Lopes writes:
>
>> As a result, if I forget to provide a filename to "M-x grep" it will
>> run forever, waiting for me to kill it.
>
> Richard M Stallman writes:
>
>> So, my grep program supports "-H" but it apparently has not the
>> expect
here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
absence of a detailed gdb GC debugging which I dont know how to do, does
this help?
Exception: STATUS_ACCESS_VIOLATION at eip=610C4974
eax=21121CB8 ebx=8014 ecx=2005 edx= esi=A1121CC8
edi=A315B51C
ebp=0
emacs user wrote:
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging which I dont know how to do, does
> this help?
I don't know anything about emacs, but I don't think this will help
anyone find the problem. A stack trace witho
Luc Teirlinck wrote:
Lennart Borgman wrote:
I think it is quite confusing that you can move the point into the
prompt area in the minibuffer. Why don't we use something like the code
below to avoid this:
As I already pointed out, I personally do not find this confusing, but
very usefu
Emilio Lopes writes:
> As a result, if I forget to provide a filename to "M-x grep" it will
> run forever, waiting for me to kill it.
Richard M Stallman writes:
> So, my grep program supports "-H" but it apparently has not the
> expected semantics.
> That is a very vague statement. It
64 matches
Mail list logo
