Two issues:
1. activate-mark-hook and deactivate-mark-hook do not have docstrings,
even though they are documented in the Emacs Lisp reference manual (Elisp
-> Markers -> The Mark).
2. If push-mark-command is run with no prefix arg and mark already set at
the current position, it activates the ma
| Is there no hope to see the 'facemenu-keymap moved to another key and have
| the goto-line solely for M-g?
|
| What other key do you suggest? M-o would be ok, if people want.
M-o is fine and looks well accessible.
Jari
___
Emacs-devel mai
Jason Rumney wrote:
New users will be used to blinking cursors from the other apps they
use, only a few experienced Emacs users who use nothing else will
be offended by the blinking, and they can easily figure out how to
disable it.
Look, I feel like I have to react to this. Your quo
Miles Bader wrote:
If some people are really physically repulsed by it to the degree Luc
professes (I admit, I suspect hyperbole),
Your suspicions are wrong.
Anyway, we've already had this flame war.
I did not subscribe to this site at that time. I did not propose to
change the defaul
On Wed, 02 Mar 2005 21:27:47 -0500, Richard Stallman <[EMAIL PROTECTED]> wrote:
> You make a good point that not everyone uses CVS, so ChangeLogs
> produced by CVS are not so good.
>
> What is the question you are discussing?
> What change was proposed? What does someone claim is an error
Richard Stallman <[EMAIL PROTECTED]> writes:
> term/keyswap.el is clearly obsolete; we have much better ways to
> handle that issue nowadays.
So shouldn't it be moved/removed/marked as such?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://li
Kim Storm wrote:
I don't think a user is supposed to change buffer specific options
like that - Lisp modes may do that, or if needed, the user should
do it via a hook.
A user definitely can change buffer (as opposed to mode) specific
options. `set-variable' provides for this. The Optio
> As I see it, the rationale for turning on require-final-newline is
> that a particular type of file should always end in a newline. The
> user should type RET himself, but in case he forgets to do so, Emacs
> does it for him. So (newline) should be used.
>
> That is true. But tho
You make a good point that not everyone uses CVS, so ChangeLogs
produced by CVS are not so good.
What is the question you are discussing?
What change was proposed? What does someone claim is an error?
___
Emacs-devel mailing list
Emacs-devel@
I believe that
text/enriched should be updated for RFC 1896. (Assuming that this is
still the most up to date standard. It was when I last checked.)
Importantly, other formats should be supported.
I would very much appreciate that work.
___
As I see it, the rationale for turning on require-final-newline is that a
particular type of file should always end in a newline. The user should
type RET himself, but in case he forgets to do so, Emacs does it for him.
So (newline) should be used.
That is true. But those kinds of
term/keyswap.el is clearly obsolete; we have much better ways to
handle that issue nowadays.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Is there no hope to see the 'facemenu-keymap moved to another key and have
the goto-line solely for M-g?
What other key do you suggest? M-o would be ok, if people want.
If we go that lane, it will more probably
require opening a modifier like "super" or "alt" for it. Most
I'll suggest that we leave the xassert in there for 2 more weeks --
just in case something serious pops up -- and then remove them again
and focus on finishing the release.
Since you're doing most of the work on debugging the display bugs,
my decision is to follow your judgment.
Miles
There is too much arguing on this list. The argument is a waste of
time and impedes real work, such as preparation of the release.
On nearly every issue that is raised, people argue back and forth
interminably. It is surely wasting a lot of your time, and if I read
all the messages, it would was
> You should be able to continue by typing the GDB `return' command
> and then `c'. Does it work?
Not really. I think that "abort" may be marked as "noreturn" in the
GCC header files, and so GCC does not bother keeping the stack or code
in a consistent state after return.
Pe
_Every_ option is supposed to be completely
irrelevant to the majority of people. If not, the default is wrong.
That is true. But not every option should be in the Options menu;
only the few most important options should be there.
I just started gedit and it too seems to use a blinkin
Richard Stallman <[EMAIL PROTECTED]> writes:
> Does anyone else agree that this option should be in the Options menu?
Yes. If not directly on the top level, then at least in one of the
submenus. Since Emacs has the blinking cursor enabled by default, then
there should be an easy way to disable i
With auto-image-file-mode turned on, `!' (`dired-do-shell-command')
called on a image file in the *Locate* buffer (created by the
`M-x locate' command) doesn't work, because `dired-get-filename'
puts "/:" at the beginning of the file name, and then the file name
with the leading "/:" is given as an
On Wed, 2 Mar 2005 13:44:20 + (UTC), Robert J. Chassell
<[EMAIL PROTECTED]> wrote:
> As I suggested earlier, Emacs should return to the format used by
> other user environments, and offer a non-blinking cursor by default.
I believe gnome-terminal blinks its block cursor by default (but I
don't
On Thu, 03 Mar 2005 00:10:35 +0100, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
> > I think an explicit decision should be made one way or the other.
>
> Based on the fact that _I_ don't have the necessary time to debug more
> silly xasserts, _I_ made the e
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Miles Bader <[EMAIL PROTECTED]> writes:
>
>> I think an explicit decision should be made one way or the other.
>
> Based on the fact that _I_ don't have the necessary time to debug more
> silly xasserts, _I_ made the explicit decision to disable them.
>
>
Miles Bader <[EMAIL PROTECTED]> writes:
> I think an explicit decision should be made one way or the other.
Based on the fact that _I_ don't have the necessary time to debug more
silly xasserts, _I_ made the explicit decision to disable them.
>
> At the time I enabled it, that was not clear the
Tak Ota <[EMAIL PROTECTED]> writes:
> Sat, 26 Feb 2005 15:19:03 -0800: <[EMAIL PROTECTED]> wrote:
>
>> Tak Ota <[EMAIL PROTECTED]> writes:
>>
>> > Hi Kim,
>> >
>> > Sorry I neglected having my homework done before reporting the
>> > incident. Now I've narrowed it to a specific case. Here is the
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
>On the Appearence menu, there could be a Cursor submenu with
>these choices:
>
> [x] Blinking
> Block
> < > Bar
> < > Hollow
>
> Please remember the non-selected window, too!
Based on the current func
On Wed, 02 Mar 2005 14:54:30 +0100, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
>> C-u C-u C-l to recenter at a specific line (if it is just C-u C-u
>> C-l, then prompt the user, if C-u C-u 100 C-l then recenter at
>> line 100)? I think this is quite nice, makes sense keybinding
>>
On Wed, 02 Mar 2005 21:23:50 +0100, Gaetan Leurent
<[EMAIL PROTECTED]> wrote:
> I think `C-x g´ or `C-M-g´ is a good choice for the default binding, and
> anyway people will just redefine it somewhere if they want to (I have it
> on M-g and I think I'll keep that binding).
C-x bindings are much ea
Johan Bockgård wrote on 02 Mar 2005 20:01:27 +0100:
>> I'd vote for `C-x g' or `C-M-g'.
>
> C-M-g may not work in a terminal/console.
We already have C-M-% that doesn't work in a terminal.
If you need to use one of those functions in a terminal, you just define
them on some other key and that's
C-M-g may not work in a terminal/console.
C-g should work, which is the same.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Reiner Steib <[EMAIL PROTECTED]> writes:
> I'd vote for `C-x g' or `C-M-g'.
C-M-g may not work in a terminal/console.
--
Johan Bockgård
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Example: How would students/designers use Emacs for PHP coding,
where the remote site displays error messages and line numbers
in a web page?
Not to distract you all from the burning issue of `M-g', but how about a
poor-man's compile buffer? If the target line number is already display
> Date: Wed, 2 Mar 2005 13:32:58 + (UTC)
> From: "Robert J. Chassell" <[EMAIL PROTECTED]>
>
> Jason Rumney <[EMAIL PROTECTED]> wrote
>
> I don't see how a video capture program could be considered a
> model for how a text editor should work.
>
> Emacs is much more than a text editor
> CC: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-devel@gnu.org
> From: [EMAIL PROTECTED] (Jari Aalto+mail.emacs)
> Date: Wed, 2 Mar 2005 10:31:13 +0200
>
> | > Please, we had an extremely prolonged discussion about this not long
> | > ago, let's not have it again!
> |
> | I agree. Its only worth
> Date: Wed, 2 Mar 2005 11:06:16 -0500 (EST)
> From: "Chong Yidong" <[EMAIL PROTECTED]>
>
> Is this file really necessary? The file is short enough to be easily
> merged into the Emacs manual.
The idea behind introducing it was that any docs for features that are
minor or too obscure or unimporta
> C-x g is also bad, it has a already existing keybinding since a
> long time.
>
> C-u C-u C-l, C-x C-g, C-s NN, all seem like good candidates. Can
> some Emacs developer just pick one, and define it to goto-line
> and kill this stupid thread?
IMHO, `C-x C-g' is a bad choice,
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
> As I suggested earlier, Emacs should return to the format used by
> other user environments, and offer a non-blinking cursor by default.
All editing applications I know use a blinking vertical bar for text
entry. So your proposal is not a questi
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
>On the Appearence menu, there could be a Cursor submenu with
>these choices:
>
> [x] Blinking
> Block
> < > Bar
> < > Hollow
>
> Please remember the non-selected window, too!
>
> Consider a default mou
On Wed, Mar 02 2005, Alfred M. Szmidt wrote:
> C-x g is also bad, it has a already existing keybinding since a long
> time.
>
> C-u C-u C-l, C-x C-g, C-s NN, all seem like good candidates. Can some
> Emacs developer just pick one, and define it to goto-line and kill
> this stupid thread?
IMHO, `
On Wed, Mar 02 2005, Gaetan Leurent wrote:
> The gnus version included with emacs CVS is buggy:
>
> In lisp/gnus/nnrss.el, ligne 765 is
> (if (and ns (not (eq ns "")))
> but should obviously be
> (if (and ns (not (string= ns "")))
>
> The is corrected in gnus CVS since version 7.11 (2004/
For example on my system gdb mode has problems finding the right
header files when stepping through code, so I have to go to those
lines manually.
Then this is a bug in gdb-mode, not the fault of a missing keybinding.
Could people stop arguing why a keybinding is needed for goto-line? I
On the Appearence menu, there could be a Cursor submenu with
these choices:
[x] Blinking
Block
< > Bar
< > Hollow
Please remember the non-selected window, too!
Consider a default mouse user interface like this for a Cursor menu in
Options that applies
Can someone please tell me when an hourglass is shown on X Emacs? Is it
shown for an operation like ediff-buffers (that takes a long time on my pc)?
Is it shown for indent-region?
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/ma
In the man/ directory there's a file, emacs-xtra.texi, which creates an
Info file that "contains detailed information about various features that
are too specialized to be included in the Emacs manual". Currently, this
is around 250 lines documenting (i) auto-reverting non-file buffers and
(ii) sub
Richard Stallman <[EMAIL PROTECTED]> writes:
> IIRC defadvice has some support for such things (e.g. you can
> add an advice even before the function is defined). Maybe it'd
> be a good idea to implement debug.el in terms of advice.
>
> Right now, the code to implement debug on entry
|Would anyone really consider facemenu-keymap to be more important,
|more essential than the primitive goto-line functionality?
|
| Yes, the majority doesn't do PHP programming.
That paragraph does not say anything about any particular use of
programming languages. Please understand that
|goto-line is so often used (when you need it; like during PHP
|coding)
|
| You have only noted PHP as needing goto-line, this doesn't warrant
| binding it globally. What about binding M-g in php-mode to goto-line?
I presented several examples. Please refer to other posts. The sources fo
On Wed, 02 Mar 2005 14:52:07 +0100, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
>goto-line is so often used (when you need it; like during PHP
>coding)
>
> You have only noted PHP as needing goto-line, this doesn't warrant
> binding it globally. What about binding M-g in php-mode to goto-
David Kastrup <[EMAIL PROTECTED]> writes:
> Richard Stallman <[EMAIL PROTECTED]> writes:
>
>> Does anyone else agree that this option should be in the Options menu?
>>
>> What do other applications do about this? My version of mozilla has
>> no way to change whether the cursor blinks, but it is r
Arguing "you should follow the true path of enlightenment because I
know better than you" is just ridiculous,
Look, you obviously didn't read anything of what I wrote, I never
argued or implied that one shouldn't bind a key to goto-line; I even
suggested that it _should_ be bound to a key.
Would anyone really consider facemenu-keymap to be more important,
more essential than the primitive goto-line functionality?
Yes, the majority doesn't do PHP programming.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mail
> C-u C-u C-l to recenter at a specific line (if it is just C-u C-u
> C-l, then prompt the user, if C-u C-u 100 C-l then recenter at
> line 100)? I think this is quite nice, makes sense keybinding
> wise.
Two C-u's plus a number...? That seems pretty convoluted...
Why do you thin
> have M-g as goto-line or else". I really feel that the use of
> goto-line to warrant a single char key binding is overblown--specially
> for a single keystroke binding!; if people use it that often then one
> should write a proper mode for Emacs to ease whatever one is doing
> instead of introdu
goto-line is so often used (when you need it; like during PHP
coding)
You have only noted PHP as needing goto-line, this doesn't warrant
binding it globally. What about binding M-g in php-mode to goto-line?
___
Emacs-devel mailing list
Emacs-dev
[EMAIL PROTECTED] (Jari Aalto+mail.linux) writes:
> |Nobody explained good arguments why current M-g is immovable?
> |
> | ,
> | | http://lists.gnu.org/archive/html/emacs-devel/2004-03/msg00642.html
> | | From: Richard Stallman
> | |
> | | "I want Emacs to move in the direction of doing
Today's GNU Emacs CVS snapshot, Wed, 2005 Mar 2 11:50 UTC
GNU Emacs 22.0.50.13 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
started with
/usr/local/src/emacs/src/emacs -Q
As suggested, I just tried out
(setq cursor-type 'hollow)
for my selected window.
In summary, I find it irritating to
In today's GNU Emacs CVS snapshot, Wed, 2005 Mar 2 11:50 UTC
GNU Emacs 22.0.50.13 (i686-pc-linux-gnu, GTK+ Version 2.6.2)
started with
/usr/local/src/emacs/src/emacs -Q
M-o is undefined;
C-x C-g is undefined;
C-x g runs the command insert-register-compatibility-binding.
Alfred M. Szmi
Richard Stallman wrote:
Does anyone else agree that this option should be in the Options menu?
What do other applications do about this? My version of mozilla has
no way to change whether the cursor blinks, but it is rather old.
Very few applications let you change the type of cursor they use.
Jason Rumney <[EMAIL PROTECTED]> wrote
I don't see how a video capture program could be considered a
model for how a text editor should work.
Emacs is much more than a text editor. It is an integrated
environment, one of four kinds of user interface that are in common
use.
It is wron
Richard Stallman <[EMAIL PROTECTED]> writes:
> Does anyone else agree that this option should be in the Options menu?
>
> What do other applications do about this? My version of mozilla has
> no way to change whether the cursor blinks, but it is rather old.
I think the contentious issue is that
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> But what is wrong with C-x ~ for example?
This is a rather suboptimal choice because ~ is difficult to type on many
keyboards. Personally, I have put goto-line on [f1] already a very long
time ago and don't care about any default binding.
Andreas
On Wed, 02 Mar 2005 12:30:31 +0100, Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
> C-u C-u C-l to recenter at a specific line (if it is
> just C-u C-u C-l, then prompt the user, if C-u C-u 100 C-l then
> recenter at line 100)? I think this is quite nice, makes sense
> keybinding wise.
Two C-u's pl
|Nobody explained good arguments why current M-g is immovable?
|
| ,
| | http://lists.gnu.org/archive/html/emacs-devel/2004-03/msg00642.html
| | From: Richard Stallman
| |
| | "I want Emacs to move in the direction of doing word processing. It
| | may take years, but we will get there.
> In <[EMAIL PROTECTED]> Richard Stallman wrote:
>> We should modify `makeinfo' to handle Japanese Texinfo, if need be.
>> `makeinfo' is faster and `texinfmt.el' was deprecated a long time ago.
> It is just what I am hoping!
> Have you reported this problem to [EMAIL PROTECTED]
No, I ha
Miles Bader <[EMAIL PROTECTED]> writes:
> On Wed, 02 Mar 2005 10:13:34 +0100, Kim F. Storm <[EMAIL PROTECTED]> wrote:
>> Well, the experience from enabling xasserts definitely shows that
>> they cannot be "safely enabled".
>
> Hey let's map in page zero too -- who wants those annoying
> NULL-point
Hi.
Using CVS emacs, loading a empty .emacs disables which-func-mode:
emacs -Q
M-x which-func-mode
load empty .emacs
C-x C-f .emacs
now which-fund-mode is disabled.
The reason is that which-func-update catches an error from
imenu--make-index-alist and then disables which-func-mode.
This patch h
On Wed, 02 Mar 2005 12:44:27 +0100, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> > But I think it should an explicit decision to that effect.
>
> I don't remember an explicit decision was made before you enabled the
> xasserts. So why is an explicit decision needed to disable them?
I think an expli
Miles Bader <[EMAIL PROTECTED]> writes:
> On Wed, 02 Mar 2005 10:13:34 +0100, Kim F. Storm <[EMAIL PROTECTED]> wrote:
>> Well, the experience from enabling xasserts definitely shows that
>> they cannot be "safely enabled".
>
> Hey let's map in page zero too -- who wants those annoying
> NULL-point
Miles Bader <[EMAIL PROTECTED]> writes:
>
> But I think it should an explicit decision to that effect.
I don't remember an explicit decision was made before you enabled the
xasserts. So why is an explicit decision needed to disable them?
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
| The following message is a courtesy copy of an article
| that has been posted to gmane.emacs.devel as well.
|
| Once again, I suggest C-x g as a binding for goto-line. The old C-x g
| binding is still available as C-x r g, if I'm not mistaken.
goto-line is so often used (when you need it; like
IIRC defadvice has some support for such things (e.g. you can add an advice
even before the function is defined). Maybe it'd be a good idea to
implement debug.el in terms of advice.
Right now, the code to implement debug on entry is so simple that it
would be a shame to use something
Should we move it lisp/obsolete?
Apparently it is still useful for something, so I guess not.
At least not now.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Fixing a user
interface design inconsistency that leads to bad results in marginal
cases is to be weighed against the likelihood of the respective fix
introducing more severe problems that might go unnoticed before the
release.
This fix is localized. It has a minor problem,
Does anyone else agree that this option should be in the Options menu?
What do other applications do about this? My version of mozilla has
no way to change whether the cursor blinks, but it is rather old.
___
Emacs-devel mailing list
Emacs-devel@gnu.o
Does anyone understand the features of Font Lock enough to
implement proper handling or btex...etex?
--- Start of forwarded message ---
X-Injected-Via-Gmane: http://gmane.org/
To: emacs-pretest-bug@gnu.org
From: Stephan Hennig <[EMAIL PROTECTED]>
Date: Tue, 01 Mar 2005 01:19:01 +0100
X-Gma
> We should modify `makeinfo' to handle Japanese Texinfo, if need be.
> `makeinfo' is faster and `texinfmt.el' was deprecated a long time ago.
It is just what I am hoping!
Have you reported this problem to [EMAIL PROTECTED]
Would you like to work on code for Makeinfo to do this?
___
If I instead use
#define RECORD_INPUT do { ; } while (0)
it works. So either gcc is broken with regard to local labels, or it
produces something from them which confuses the dumper.
The way to debug a problem like that is by looking at the assembler
code and seeing if it corresp
Nobody explained good arguments why current M-g is immovable?
,
| http://lists.gnu.org/archive/html/emacs-devel/2004-03/msg00642.html
| From: Richard Stallman
|
| "I want Emacs to move in the direction of doing word processing. It
| may take years, but we will get there. Then commands to
Miles Bader <[EMAIL PROTECTED]> writes:
> On Wed, 02 Mar 2005 00:52:13 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
>> I find it highly embarrassing that I have to tell people that want
>> to test drive Emacs without becoming a debugger-savvy developer
>
> Why do you find it "embarrassing"?
B
In article <[EMAIL PROTECTED]>, Werner LEMBERG <[EMAIL PROTECTED]> writes:
> About nine months ago I wrote the following:
>> I've finally replaced the Thai word list of unknown origin with a
>> list taken from IBM's ICU4J project which uses the X license. In
[...]
> Is there any progress?
I'
On Wed, 02 Mar 2005 00:52:13 +0100, David Kastrup <[EMAIL PROTECTED]> wrote:
> I find it highly embarrassing that I have to tell people that want to
> test drive Emacs without becoming a debugger-savvy developer
Why do you find it "embarrassing"? Is it surprising to these people
that a develop tr
On Wed, 02 Mar 2005 10:13:34 +0100, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> Well, the experience from enabling xasserts definitely shows that
> they cannot be "safely enabled".
Hey let's map in page zero too -- who wants those annoying
NULL-pointer dereference bug reports?
-Miles
--
Do not tau
About nine months ago I wrote the following:
> I've finally replaced the Thai word list of unknown origin with a
> list taken from IBM's ICU4J project which uses the X license. In
> case it is not possible to use this data directly within GNU stuff,
> I suggest to move the word list into a separ
Once again, I suggest C-x g as a binding for goto-line. The old C-x g
binding is still available as C-x r g, if I'm not mistaken.
Kai
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
David Kastrup <[EMAIL PROTECTED]> writes:
> It would be one thing if I could see that it does in any manner
> improve our chance of getting _valuable_ feedback (instead of "it
> crashed, and even had I been running it in a debugger, the screen
> would no longer be updated to show what I had been d
Miles Bader <[EMAIL PROTECTED]> writes:
>>The right answer is to change those xasserts (and _only_ those) which
>>cause a problem or test something silly or are insanely inefficient
>>
>> How do we find and recognize all of those?
>
> In order to demonstrate that the majority are superflu
On Sat, 26 Feb 2005 19:21:28 -0500, Francis Litterio
<[EMAIL PROTECTED]> wrote:
> In lisp/button.el, function make-button sets the type of the button to a
> default value if the user doesn't supply a :type property, but function
> make-text-button does not.
Thanks; I've fixed this (in a slightly d
* Alfred M. Szmidt (2005-03-02) writes:
>I am using it often when dealing with patches generated with `diff'
>and wanting to look at the original source before applying a patch.
>
> That is what `diff-mode' and C-c C-c (or ) is for. So once
> again, I fail to see what use goto-line has fo
| > Please, we had an extremely prolonged discussion about this not long
| > ago, let's not have it again!
|
| I agree. Its only worth opening again if something has changed since the
| last discussion.
There is really a need to discuss this, because I see daily situations
where we need the got
88 matches
Mail list logo
