The following contains less irrelevant clutter than my previous ielm run.
`emacs -Q' `M-x ielm RET', then:
***nil
Welcome to IELM *** Type (describe-mode) for help.
ELISP> (compile-defun (lambda ()))
nil
ELISP> (load "~/longlines.elc")
t
Message appears.
Sincerely,
Luc.
___
Richard Stallman wrote:
I do not do much web searching. Could you explain the difference?
Basically, as usual in web searching, most of the hits produced by the
searches of either Per or Kim are false hits, both in the case of
"blinking cursor" and "fringe". I do not fancy going through all
Chong Yidong wrote:
I can't reproduce this, and it doesn't make sense; longlines-mode is
defined using define-minor-mode, which should do the variable definition
properly. Could you look into this further? Maybe it is something in your
.emacs.
I believe that the following should be re
In Emacs 21.3, Text mode did not override the default value of
require-final-newline. In current CVS, it does. Is there a
reason for that?
I think we did discuss that question leading up to my decision
to introduce mode-require-final-newline. However, there is
p
In lispref/display.texi:
The @code{:height} and @code{:align-to} properties are supported on
non-graphic terminals, but the other space properties in this section
are not.
Is it correct that :height is supported on non-graphic terminals?
NEWS says it is :width.
___
If I understand things correctly, the problem would go away, if
require-f-n would just add the newline when writing the file but not
to the buffer (a bit similar to a function in
`write-region-annotate-functions') . Then the user would only come to
see it, if she reverts the buf
> A google search on "emacs turn off blinking cursor (without the
quotes)
> gives around 1 hits. That is 10 times more than a similar search
> with "blinking cursor" replaced by "fringe", but only a fifth than the
> search for "tool bar" or "menu bar".
>
The only solution (within the current implementation) that I can
think of, is to temporarily remove all debug-on-entry code while
stepping with `d'.
Would setting inhibit-debug-on-entry temporarily do the job?
I can think of two points in a macro to set a break for the
I propose the following fixes for html-mode in sgml-mode.el.
1. With sgml-xml-mode=t HTML skeletons insert empty XHTML elements
without a space before the trailing `/>'. But HTML compatibility
guidelines recommend using such a space for compatibility with
existing HTML user agents (i.e. `' instea
"Luc Teirlinck" <[EMAIL PROTECTED]> wrote:
>It would be useful for a few experienced Emacs developers to look it
>[longlines.el] over and make suggestions.
>
> I am not really the best person to make suggestions. It would be
> better if longtime users did. Here are some remarks.
> ...
>
>From my previous message:
I suggest that longlines treats final newlines the same way AbiWord does.
I should have been more explicit here (and elsewhere). When I
referred to "what AbiWord does" I meant: "what Abiword does when
saving in the (plain) Text format".
Sincerely,
Luc.
Richard Stallman wrote:
If he did not finish the paragraph, he will probably assume the
newline is soft. If he did finish the paragraph, he will probably
assume the newline is hard.
The way I see it, if use-hard-newlines is enabled, the user finishes a
paragraph by explicitly typing a n
Nic Ferrier <[EMAIL PROTECTED]> writes:
> chad brown <[EMAIL PROTECTED]> writes:
>
>> If you don't even have a /usr/share/dict/words file, then I'd say that
>> Debian has evolved out from under emacs-ispell -- most systems I use
>> still have such (although mostly under the just-mentioned path).
Oliver Scholz wrote:
If I understand things correctly, the problem would go away, if
require-f-n would just add the newline when writing the file but not
to the buffer (a bit similar to a function in
`write-region-annotate-functions') .
That would be OK for longlines to do but not for
"Robert J. Chassell" <[EMAIL PROTECTED]> writes:
> Jason Rumney rightly noted that
>
> In the Emacs manual, we need to explain how the user configures
> this in Emacs. Describing what RFC2616 says is not very useful
> ...
>
> Good point. How about putting the explanation in a comment
Richard Stallman wrote:
BTW, longlines.el seems to be fairly widely used; is there a reason it
hasn't been added to the Emacs distribution?
It would be useful for a few experienced Emacs developers to look it
over and make suggestions.
I am not really the best person to make
Jason Rumney rightly noted that
In the Emacs manual, we need to explain how the user configures
this in Emacs. Describing what RFC2616 says is not very useful
...
Good point. How about putting the explanation in a comment in
emacs/lisp/url/url-vars.el
just after
(defvar url-m
If you don't even have a /usr/share/dict/words file, then I'd say that
Debian has evolved out from under emacs-ispell -- most systems I use
still have such (although mostly under the just-mentioned path).
*chad
On 7 Mar, 2005, at 17:06, Nic Ferrier wrote:
in CVS emacs-ispell's lookup-words funct
> . This combination of "is" and "since" is incorrect English usage.
I think "is ... since" is pretty common usage actually, and certainly
makes sense.
-Miles
--
Do not taunt Happy Fun Ball.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://li
chad brown <[EMAIL PROTECTED]> writes:
> If you don't even have a /usr/share/dict/words file, then I'd say that
> Debian has evolved out from under emacs-ispell -- most systems I use
> still have such (although mostly under the just-mentioned path).
That seems a shame since lookup-words is used
in CVS emacs-ispell's lookup-words function is doing a grep on
/usr/dict/words.
On my very up to date debian (testing) machine I don't have a
/usr/dict/words file. I don't even have a words file. I seem to have
lots of hash files but no textual words file.
Is this a bug with debian or with emacs-
Mark a function obsolete with:
(make-obsolete 'foo 'bar "21.4")
Compile another function which calls `foo'. The following warning
appears in the *Compile-Log*:
While compiling toplevel forms:
** `foo' is an obsolete function since 21.4; use
`bar' instead.
. This combination of "is" and
Robert J. Chassell wrote:
Thanks to Andreas, Jason, and Nic I think I now understand the rfc2616
HTTP specification a great deal better than before.
Perhaps we should add the following to
emacs/man/url.texi
after the text saying:
@node HTTP language/coding
@subsection Language and Encoding
On Sat, 05 Mar 2005, [EMAIL PROTECTED] wrote:
>I am curious if there's a chance GNU Emacs will ever have an embedded
>web browser object through the Mozilla GTK support:
>
> Let's please not discuss this now. We are not working on new features
> now. What we want to do now is prepare fo
From: Roar =?ISO-8859-1?Q?Thron=E6s?= <[EMAIL PROTECTED]>
Date: Fri, 25 Feb 2005 16:28:09 +0100
[...] port of Emacs 21.2 to VMS.
hi Roar,
porting work continues. in cvs, see branches ttn-vms-21-2-stash and
ttn-vms-21-3-stash for (the small trickle) of checkins. i think i will
make ava
> I see you implemented this. This makes debug-on-entry for macros a
> lot better, of course. Thanks. But the problem I mentioned remains:
> the debug-entry-code is visible.
[...]
> Debugger entered--entering a function:
> * (lambda (var) (if (or inhibit-debug-on-entry debugger-jumping-flag) nil
Thanks to Andreas, Jason, and Nic I think I now understand the rfc2616
HTTP specification a great deal better than before.
Perhaps we should add the following to
emacs/man/url.texi
after the text saying:
@node HTTP language/coding
@subsection Language and Encoding Preferences
H
On Fri, Mar 04 2005, Reiner Steib wrote:
> On Tue, Mar 01 2005, Stefan Monnier wrote:
>
>> Reiner Steib wrote:
>>> I propose to add autoloads for all iso-8859-* and windows-125* coding
>>> systems. With these autoload, Gnus (and probably also other Emacs
>>> based mail and news readers) are able
Stefan Monnier <[EMAIL PROTECTED]> writes:
>>I can think of two points in a macro to set a break for the
>>debugger: just before macro expansion and just after it, right
>>before the evaluation of the resulting sexp. In both cases,
>>hiding the debug-on-entry code from the user of
drkm <[EMAIL PROTECTED]> writes:
> Really?-)
Ouch. That should have been:
unsigned debug_on_entry : 1;
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo
[EMAIL PROTECTED] (Kim F. Storm) writes:
> You could define a bit in the Lisp_Symbol, like this:
> struct Lisp_Symbol
> {
[...]
> unsigned debug_on_entry;
^^^
Really?-)
--drkm
___
Emacs-devel mailing list
Emacs-dev
Hi
Why does PS Print impose user functions (in `ps-left-header' for
example) to be symbols? `ps-generate-string-list' and
`ps-generate-header-line' use `symbolp' and `fboundp' instead of
`functionp'. Why don't use the following, to allowing lambdas in PS
Print customs:
*** ps-print.el-orig
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Stephan Stahl" <[EMAIL PROTECTED]>
>
>> I think shell-quote-argument should not use
>> (eq system-type'windows-nt)
>> instead it should take shell-file-name into account.
>>
>> It seems very usual for emacs use
Lute Kamstra <[EMAIL PROTECTED]> writes:
> When I was thinking about these three problems, it seemed to me that
> the easiest and simplest thing to do, is to move support for
> debug-on-entry into the C implementation of the Lisp interpreter. To
> mark a function for debug-on-entry, you could set
I checked out Emacs from CVS today. The standard build is OK, but I'm
trying to build it with make-package so that all files are contained in
Emacs.app:
$ cd mac
$ ./make-package --self-contained
Version numbers are 22.0.50 and 22.0
Building in directory
/Users/andrew/Desktop/emacs/mac/make-pac
- Original Message -
From: "Stephan Stahl" <[EMAIL PROTECTED]>
> I think shell-quote-argument should not use
> (eq system-type'windows-nt)
> instead it should take shell-file-name into account.
>
> It seems very usual for emacs users on w32 to use cygwin or mingw.
> Right now shell-quote
>I can think of two points in a macro to set a break for the
>debugger: just before macro expansion and just after it, right
>before the evaluation of the resulting sexp. In both cases, hiding
>the debug-on-entry code from the user of the debugger seems not
>possible.
To me "e
Hi.
I think shell-quote-argument should not use
(eq system-type'windows-nt)
instead it should take shell-file-name into account.
It seems very usual for emacs users on w32 to use cygwin or mingw.
Right now shell-quote-argument would return something wrong when bash
or some "intelligent" shell is
Debug-on-entry currently changes the definition of functions by adding
code that enters the debugger. This code needs be hidden from the
user of the debugger, which can be hard. Redefining the function also
removes this code and thus cancels debug-on-entry, which is
inconvenient. I'll give some
Richard Stallman <[EMAIL PROTECTED]> writes:
> Because, everywhere else in the buffer, the newline at the end of a
> paragraph is hard.
>
> That doesn't seem like a convincing reason.
>
> Now suppose the user goes to another buffer to do his editing, and comes
> back to this buffer
40 matches
Mail list logo
