I've told you my decision. Please drop this issue.
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
> Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org,
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Wed, 01 Jun 2005 17:28:45 -0400
>
> >> the TABs in info buffers don't come from Emacs but from actual info
> >> files (generated by makeinfo, or insta
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
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 mailin
Hi,
I'm troubled with Emacs crashing since yesterday when executing
some emacs-w3m command. I haven't succeeded in identifying of
the Lisp code of the cause yet, though. Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0809704f in lisp_string_width (string=149514347, p
Place the following in the middle of a buffer (with text following):
`[(,test ,)]
Set the point right after the (malformed) expression and hit C-x C-e.
You will find that an error is correctly reported (invalid-read-
syntax ")"), but that the complete rest of the buffer (after the
point) IS D
When a modified buffer is killed through some mouse action, I get a
``yes-or-no-p'' question in form of a single submenu drawn on the
screen, in the middle of the frame.
When I then click somewhere else in the frame (outside the menu), the
adopted semantics are "no" rather than "quit". yes-
+This works fine in text mode.;
^ ^
+But if you switch to `emacs-lisp-mode', the guillemots match adjacent words.;
^ ^ ^ ^
,
| show-paren-mode's value is t
`
,
| When Show Paren mode i
On 6/2/05, Drew Adams <[EMAIL PROTECTED]> wrote:
> TAB characters are a pretty standard part of Emacs culture; a
> restriction on their use would require enforcement to be effective. A
> program that doesn't deal with tabs is likely to experience them
> anyway.
>
> The same argume
>> the TABs in info buffers don't come from Emacs but from actual info
>> files (generated by makeinfo, or install-info, or by hand).
> install-info doesn't change the Info files it installs in any way.
It does: the "dir" file.
Stefan
___
Em
> From: Stefan Monnier <[EMAIL PROTECTED]>
> Date: Wed, 01 Jun 2005 11:28:48 -0400
> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
>
> the TABs in info buffers don't come from Emacs but from actual info
> files (generated by makeinfo, or install-info, or by hand).
install-info doesn't change t
Saving a modified file i am allowed to access (owner) in a directory i
am not allowed to write in (no new files allowed). Emacs seems to hang,
but quitting works, and with debug-on-quit t:
Debugger entered--Lisp error: (quit)
copy-file("/etc/apt/sources.list" "/etc/apt/sources.list~" t t excl)
> "KFS" == Kim F Storm <[EMAIL PROTECTED]> writes:
KFS> The problem turned out to be nested calls to format-mode-line,
KFS> which caused internal data pointers to be altered in unexpected
KFS> ways.
KFS> I have just installed a patch to fix this. Pls. try it.
It works well no
I don't have a problem serious enough to warrent the change. I just don't
see why Info should have TABs. I don't suggest this as an urgent or
important problem, but as something that might be changed over time. If
there is no reason for Info to use TABS, then why use them?
They mak
I've noticed a serious problem when I do W C to save merge results. If the
destination file already exists I get prompted to overwrite. After typing Y to
that prompt I find that ediff has saved it's own help buffer and not the `C'
buffer. That is, the destination file contains only:
? -qu
AFAICT these are different situations: the TABs in info buffers
don't come
from Emacs but from actual info files (generated by makeinfo, or
install-info, or by hand).
True. And some Info files available have nothing to do with Emacs. And some
have nothing to do with GNU.
So perhap
> The same argument could be made for *Help*, or Dired, or *Apropos*, or
> *Buffer List*, or Those buffers don't use TABs, but there is no
> "restriction on their use" or any explicit "enforcement" to not use TABs,
> AFAIK.
AFAICT these are different situations: the TABs in info buffers don't
>> The attached file contains the top and bottom of a Lisp backtrace I got from
>> C-g, after enabling enter debugger on quit.
> Indeed it looks like a loop/recursion bug in EDE.
> So can we conclude that emacs does not _crash_ ?
And since C-g works as well, it's not frozen.
I.e. it's not an Em
> If there is no reason for Info to use TABS, then why use them?
TAB characters are a pretty standard part of Emacs culture; a
restriction on their use would require enforcement to be effective. A
program that doesn't deal with tabs is likely to experience them
anyway.
The sa
"Steven T. Hatton" <[EMAIL PROTECTED]> writes:
> The attached file contains the top and bottom of a Lisp backtrace I got from
> C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
--
Kim F. Storm <[EMAI
> Nick Roberts writes:
> > I have written some code that removes the mouse-face property for
> > inactive entries, and adds a face inherited from
> > font-lock-comment-face; see attached. I think this does what you
> > want regarding selection.
> I prefer this behaviour for selection bu
> > The nonselectable items, are still selectable from the completions
> > buffer with mouse-1 or . They just do nothing and return to
> > the original buffer. I guess this is consistent with clicking on a
> > nonselectable menu-item but in this case its clearer that you
> > haven't selec
On 6/1/05, Drew Adams <[EMAIL PROTECTED]> wrote:
> I don't have a problem serious enough to warrent the change. I just don't
> see why Info should have TABs. I don't suggest this as an urgent or
> important problem, but as something that might be changed over time. If
> there is no reason for Info
22 matches
Mail list logo