The buffer is font-locked incorrectly, see the attached screen shot:
[...]
It seems like the unbalanced backquote in the comment «# force `ro» in
combination with the two «echo ... \\» confused font-lock.
I don't see anything wrong in the screen shot.
Sorry, for some reason this screen
Visit a file that you have modified in another emacs session.
Emacs asks what you want to do about the lock. Hit ? to popup the
*Help* window in a new frame. After the frame has appeared, I get an
immediate:
Debugger entered--Lisp error: (error Non-character
I don't have any strong objection to the patch other than the fact that it
feels wrong: DND events are normal user-initiated commands so I think they
should be handled normally.
The idea of special-event-map is to handle events that are solitaries
and could arrive in the middle
This doesn't explain why (find-file-noselect ~/) and
(find-file-noselect ~/Application Data/) return the same buffer.
Shouldn't they be differnet no matter what ~ expands to?
find-file-noselect calls (abbreviate-file-name (expand-file-name FILE)),
where expand-file-name is implemented in C
I didn't like Emacs' default choice for HOME --
%USERPROFILE%\Application Data.
Stefan Since when is that the default?
* Changes in Emacs 22.1 on non-free operating systems
+++
** The HOME directory defaults to Application Data under the user profile.
Huh? I thought we had agreed to use
Huh? I thought we had agreed to use %USERPROFILE% instead (which is
usually closer to Unix's $HOME).
%USERPROFILE% is not defined on some versions of Windows, and it is not one
of the standard locations available through system calls. No other Windows
application writes directly in this
Hmm... I thought that was exactly my point: DND events, being
user-initiated, should *not* arrive in the middle of a key sequence.
Why shouldn't they? Are you saying that it just isn't right
for users to do a drag-and-drop while having entered an incomplete
key sequence?
Yes, kind
No, I'm saying that using CSIL_PROFILE is right when that place exists
(when PROFILE is the longest common prefix of all interesting places), and
that when it's not, we can still use that because it's not obviously worse
than any other.
How are you proposing that we still use it, when it
Why shouldn't they? Are you saying that it just isn't right
for users to do a drag-and-drop while having entered an incomplete
key sequence?
Yes, kind of like using the menubar in the middle of a key sequence.
But it isn't the same. The menu bar is a way to give Emacs commands.
When Emacs writes out an auto-save file, Emacs doesn't set its
eol type explicitly. So CR/LF is selected for it on Windows.
Good catch.
setup_coding_system (Qemacs_mule, coding);
We could either use Qemacs_mule_unix here or change `emacs-mule' to always
use LF (after all, it's supposed to
The comment suggests that this patch will create a problems. Perhaps the
patch below solves them.
I think the problem is just an oversight in the following change:
2003-07-15 Stefan Monnier [EMAIL PROTECTED]
* buffer.c (Fswitch_to_buffer): Don't signal an error when switching
OK, I've installed this change. I notice that sometimes Fcar and Fcdr
are used instead of XCAR and XCDR eg.
this change:
if (NILP (norecord) !EQ (buffer, XCDR (XCAR (Vbuffer_alist
in window.c:
w- buffer = Fcdr (Fcar (Vbuffer_alist));
When is it ever better to use the
We could do the same as the print of long Lisp values ... showing
only some bindings followed by ... -- and make it clickable with the
mouse to show the whole thing.
(setq truncate-lines t) does pretty much just that except that it uses the
fringe marker rather than
That
I, and I think many others, turn the fringe off for that reason - and
because it is noisy/busy/distracting. I never need it, and I hope to never
need it in the future. If we start using fringe as the sole vehicle for some
functionality, making that feature available _only_ through the fringe,
I notice when I exited emacs, my laptop fan soon was able to take rest
breaks. With an emacs running, even idle, the fan never stops!
(Well sometimes it never stops anyway (Celeron M, no power saving))
try (setq jit-lock-stealth-time nil) in your .emacs.
Stefan
When this item is in the mode map, selecting any menu item seems to
deactivate the mark, if it was defined by dragging with the mouse. Eg:
M-x fortran-mode
click and drag with mouse-1 to highlight a region
Tools- Spell Checking-Spell-Check region
The mark is not active now
I don't see why
nice on a desktop, but a pain when you're on a plane with a
laptop that is running out of power.
Not nearly as bad as when the *plane* is running out of power,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
cfengine-mode fails to colorize escaped double-quoted
Here's the smallest file I can reproduce the bug with:
# -*- mode: cfengine -*-
editfiles:
{ /etc/lilo.conf
InsertLine append=\ip=dhcp\
}
It's because of the following line in `cfengine-mode'. I don't know
Cfengine, so if
But what's the wisdom behind pushnew-internal [we already know that
PLACE is a symbol]?
This is in case we someday switch to lexical binding.
add-to-list won't work properly on lexical varables.
Ok, but why does it need a defvar ?
That tells the compiler that pushnew-internal is a
Honestly, I think using `add-to-list' here makes no sense.
Since we have the variable as a symbol and we're macro-expanding, we can
just use `(unless (member ,element ,var) (setq ,var (cons ,element ,var)))
That'll be a lot more efficient than going through a function call to
add-to-list,
Honestly, I think using `add-to-list' here makes no sense. Since we
have the variable as a symbol and we're macro-expanding, we can just
use `(unless (member ,element ,var) (setq ,var (cons ,element ,var)))
That'll be a lot more efficient than going through a function call to
Only one variable is bound - no need for let*.
Is let better than let* if you do not need it?
I believe the resulting byte-code is 100% identical.
But you save at least 1 byte in the source code. More importantly at times,
you save 1 column of indentation.
I suspect it is in some way as you
I note, too, that the only places where this function is used always
use this idiom: (or (string-key-binding key) (key-binding key t))
where the `t' is sometimes absent. This brings to mind the question
whether `string-key-binding' should in fact be a separate function,
or should just have
Actually, sometimes using let* instead of let (when defining several vars)
can result in more efficient byte-code.
I thought they generally resulted in more or less the same bytecode, the
only difference being whether the varbind byte-ops were interleaved
with the init expressions, or all
I've checked in a fix that changes UTF8_STRING to STRING if the data
doesn't look like UTF8. However, this might give errors too. The only
way to be sure to copy raw binary data correctly is by adding a new type
(like application-specific/octet-stream). But if we do that, nobody
will be
Also IIRC a perfectly valid utf-8 buffer may contain eight-bit-* chars, use
to keep track of valid unicode chars that have no corresponding character in
emacs-mule. So the presence of eight-bit-* chars does not imply that the
utf-8 encoded form of the text will contain an invalid utf-8 byte
It currently does word-granularity, and does it very well. Character
granularity would probably be too much work compared to what it would
provide.
Actually, smerge-mode (take a look at smerge-refine) does
character-granularity and it wasn't more work (quite the opposite,
actually).
It
It'd probably be best to layer the diffs: first do a word-granularity diff
and then do a char-granularity diff within words.
That's my opinion too.
But maybe that'd be too slow.
This is why I was proposing just looking at the beginning and end of
each word, which is two comparison if the
I'm not sure this is right, because windows-1252 covers basically all bytes,
so there's no way to find out that a file is not in windows-1252.
As Latin-1 (still) has a higher priority than windows-1252 (at least
that's my understanding), windows-1252 will not be used unless there a
bytes
Except for these invalid keys, you can use `read-kbd-macro' and call
`self-insert-command' on a key from `map-keymaps' to insert it (after
setting `last-command-char').
The fact that it works in most other cases is just accidental.
I see no relation between self-insert-command and the
I've examined this a bit more, and it looks like
fontification-functions are called over and over with the same
argument despite the `fontified' property being t for the whole
buffer.
Can you use the Lisp debugger to see what is calling the
fontification-functions?
The
I just caught Emacs hogging the CPU with endless
redisplay/fontification. The following code triggers it for me:
--8---cut here---start-8---
(progn
(switch-to-buffer *fontification loop*)
(emacs-lisp-mode)
(while ( (point) (floor (* (sqrt 2)
I just caught Emacs hogging the CPU with endless
redisplay/fontification. The following code triggers it for me:
--8---cut here---start-8---
(progn
(switch-to-buffer *fontification loop*)
(emacs-lisp-mode)
(while ( (point) (floor (* (sqrt 2)
I believe the patch below (more specifically the first part) fixes it.
I'm unable to trigger any looping now.
Thank you,
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
From time to time emacs starts utilizing 100% of cpu time. Sometimes it falls
back to normal usage for some seconds, but it always catches up again.
Emacs stays responsible and the only indication is that my fan is running all
the time, thus I'm not sure since when I have this problem. And I
C-h f apropos-command
In *Help*, click the link for the apropos file (upper right). It
should take you to the definition of command
`apropos-command'. Instead, it takes you to the definition of button
type `apropos-command':
Any objection to the patch below which seems to fix it?
(file ^\0-#%-),;=[-^`{-}\^? ...)
For what it's worth, GNU Arch uses file names with `{', `}', and `=' (and
`,' as well, but these are probably less important).
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Font Lock on-the-fly misfontification in C++
first raised Jul 19, last response Jul 31
Stefan Monnier posted a patch to progmodes/cc-fonts.el
for part of this bug (but it is not checked in to CVS) and
suggestion on fixing the rest of the bug
Maybe this bug got
Thanks for a clear explanation. Your fix would work fine for me. What's
important is that `accessible-keymaps' return the right result. I think
you're saying that it's not necessary for it to load the library to be able
to do that.
My fix doesn't cause accessible-keymaps to return the right
Since you don't want to update, you put extra load on us.
I do want to update. I don't want to build. I update whenever I can find a
newer binary. Right now, I'm looking forward to a pretest Windows binary
;-).
W.r.t the manual, it'd be helpful if you checked the CVS version, whose
Users may have code in .emacs that removes read-onlyness from the grep
output buffers. This local variable overwrites this to remind that
editing etc/grep.txt will lose escape sequences. With your latest change
in files.el, the local variable buffer-read-only will cause no trouble.
./configure --with-gtk CFLAGS=-pipe -O2 -g
make bootstrap
If additionally to -pipe -O2 -g you pass
-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DENABLE_CHECKING, do you
see any warning in the compilation log (especially in the compilation of
keymap.c), or some assert failure instead of the
(aset foo 0 ?\!!)
As a general rule I recommend to never use `aset' on strings. It turns out
that it's indeed rarely used, and that implementing it is stupidly tricky
and potentially much more costly than one would think.
My own local Emacs is hacked to disallow `aset' on strings and it works
My gcc command does not have an option -Wno-pointer-sign.
(gcc version is 3.4.6)
So, I tried this command.
--
./configure --with-gtk CFLAGS=-pipe -O2 -g -Wall -DUSE_LISP_UNION_TYPE
-DENABLE_CHECKING
make bootstrap
--
keymap.c's compile time warning is
--
gcc -c -I/usr/X11R6/include
(eq (char-syntax (char-after)) ?\())
Beware: fails at EOB.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
src/keymap.c 1.330OK
src/keymap.c 1.331NG
OK, so until now it seems we have discovered that the problem appeared with
this change. Funnily enough, basically 0% of the code introduced by this
change is in the latest revision (1.341).
Also it seems that removing the -O2 argument makes
Chong Yidong [EMAIL PROTECTED] wrote:
Does bootstrap fail with the following CFLAGS?
succeed with CFLAGS=-g
succeed with CFLAGS=-g -DUSE_LISP_UNION_TYPE
failwith CFLAGS=-g -O2
gcc optimization problem?
While compiler bugs are always a possibility, C has unspecified so many
parts of
(while (in-string-p)
(backward-char 1))
That's the way a snail would do it,
(goto-char (or (nth 8 (syntax-ppss)) (point)))
would be faster and solve the same problem with comments at the same time.
Stefan
___
emacs-pretest-bug
The point is that those 0.7 seconds (or whatever, on your machine) are
almost all wasted time, not productive time. There is no reason to look
up ~5000 bindings that are then ignored. If something useful were being
done for that time, I wouldn't have filed a bug. To me, this is just extra
(while (in-string-p)
(backward-char 1))
That's the way a snail would do it,
(goto-char (or (nth 8 (syntax-ppss)) (point)))
would be faster and solve the same problem with comments at the same time.
However, I'm not convinced here.
in-string-p is very clear and short written.
I'd say this design decision will certainly cause subtle bugs, such as
the one we are discussing in this thread. I suggest to modify the
design to not use encoded strings internally.
It could be, although it would make sense to manipulate group names in
encoded form, in the sense of not
I can reproduce similar results with M-x shell on GNU/Linux following
your description (terminating each multi-line with C-j is crusial!!)
It looks like redisplay fails to delete to end of line when lines
have mouse face.
Is it really a bug in Emacs, or is this just a matter
After some trial and error, I propose the following patch. I have
verified that it makes the reported bug go away. Does anyone disagree
with it?
Looks good to me,
Stefan who's never actually used Python
___
emacs-pretest-bug mailing
It could be, although it would make sense to manipulate group names in
encoded form, in the sense of not decoded.
It could ``make sense'', but it's IMO a bad idea, since, as we both
know, Emacs is not well suited to handling unibyte strings.
Huh? Unibyte strings are perfectly well
Agreed, but note that this problem is as much on the unibyte side as it is
on the multibyte side
Not if I never let unibyte strings into my buffers and strings (modulo
bugs, of course).
I don't follow. Not that it matters.
My point was simply if you stay 100% within multibyte, it all
This said, I agree that Emacs should help more. E.g. by signalling an
error when trying to insert multibyte text into a unibyte buffer.
This operation converts the string to unibyte.
Indeed. Using a default (and poorly specified) encoding method.
It works correctly, provided the
My point was simply if you stay 100% within multibyte, it all works, and if
you stay 100% in unibyte it all works
The former is true, the latter isn't, AFAIK. ``Normal'' Emacs
primitives and subroutines always do TRT with multibyte strings, while
with unibyte you need to be careful which
My point was simply if you stay 100% within multibyte, it all works,
and if you stay 100% in unibyte it all works
The former is true, the latter isn't, AFAIK. ``Normal'' Emacs
primitives and subroutines always do TRT with multibyte strings, while
with unibyte you need to be careful
,[ lisp/ChangeLog ]
| 2006-07-04 Stefan Monnier [EMAIL PROTECTED]
|
|* thingatpt.el (symbol-at-point): Don't use `form-at-point' which
|fails if the symbol contains chars like ( or '.
|(bounds-of-thing-at-point): Remove unused vars `end' and `beg'.
|(thing-at-point
I'm not quite sure what is a unibyte session
A.k.a. emacs --unibyte.
I know that, but I'm not quite sure what it entails. This discussion is
within the scope of code such as Gnus's, i.e. code which should work
either way.
but I think stay 100% in
unibyte is fairly clear: only use unibyte
It works correctly, provided the characters in that string can be
expressed in the unibyte buffer.
But which characters can be expressed is poorly specified. E.g. Tell me
which chars can be expressed in a unibyte buffer in a BIG5 locale?
Mentioning the locale is somewhat of a red
I've recently switched my kernel from i686 to amd64 without changing the
rest of my system (so all programs use the compatibility x86 mode).
This seems to work just fine overall, except that Emacs gets confused and
thinks my `long' are 64bit wide.
This apparently comes from the use of `uname' in
Yes, though I'm not interested in that fork.
Why do you consider it as a fork? AFAICT it's your code.
I advise people who want a Python mode to use what I maintain for
Emacs 21 (notwithstanding various wrinkles). Its eldoc support works.
I gave up trying to keep the original version
You can represent one of Emacs' supported Latin alphabets in
(unencoded) unibyte strings, and Emacs will automatically convert to
and from multibyte.
And this use was very convenient for Emacs-20 where we wanted to keep some
backward compatibility with code that was not MULE-aware.
But
--- server.el 02 Nov 2006 14:00:25 -0500 1.117
+++ server.el 02 Nov 2006 14:03:12 -0500
@@ -112,6 +112,7 @@
:version 22.1)
(put 'server-auth-dir 'risky-local-variable t)
+;; FIXME: This should not be a global var, but stored in the process's
plist.
(defvar server-auth-key nil
So we should simply tell whichever programs look for EMACS=t to change?
I think that is the right thing to do.
Another possibility is to switch to a different envvar name, but I
think that would make an even bigger transient.
I don't think it'll be much bigger. And it has the benefit of
When debug-on-error is enabled and an error occurs, a backtrace is
generated. Clicking on a function in the stack opens a buffer with the
cursor at the start of the function. It would be more useful to place the
cursor at the point of execution within that function.
Patch welcome for this.
Otherwise you get problem that when SWI-Prolog is run from a
Makefile that sets EMACS to emacs (or somesuch) it'll think it's
running inside Emacs.
Such circumstances are probably negligibly rare: interactive programs
(which should be the only ones that care about the EMACS envvar) are
Introducing another environment variable like INSIDE_EMACS=t to replace
EMACS=t doesn't cure the breakage to the nice programs.
I'd hate to release Emacs 22 which works worse than Emacs 21 with the
nice programs, just to make it work better in the rare cases where
someone build a specific
I do not like the idea of making it hang.
It would be nice to detect the lack of file name arguments
and output some sort of error message, but I am not sure
how to detect that condition reliably.
It's very easy if done at the right place: inside GNU grep (rather than
inside Emacs). And it
It's very easy if done at the right place: inside GNU grep (rather than
inside Emacs). And it sure should complain: the user specified a search in
0 files, so there's obviously something odd.
From grep(1):
DESCRIPTION
grep searches the named input FILEs (or standard input if no
M-x run-python RET
import os RET
help(os) RET
Fontification gets very confused when, for example, single quotes are
used as apostrophes rather than delimiting strings. It makes the
output really difficult to read.
Indeed, using the programming language's syntax-table for the inferior
! (global-set-key [right-fringe mouse-2] [mouse-2])
--- 2416,2422
! (global-set-key [right-fringe mouse-2] 'mouse-yank-at-click)
Hmm... that's nasty.
So we can't redirect a mouse event like that: the event's parameters
get lost. That sucks.
How could we do it right?
Stefan
The patch below tries to fix just this one case you complain about, but
maybe we should go a few steps further?
The patch makes the inferior Python buffer much easier to read, but it
means that strings inside double quotes are fontified, while strings
inside single quotes are, which is kind
What about the EMACS variable in term mode (the one invoked by M-x
term RET)? Currently, the variable is set to the emacs version, like
$ echo $EMACS
22.0.90.1 (term:0.96)
term should set INSIDE_EMACS as well.
I believe it's important to distinguish term from comint:
Well, it's simple enough for Emacs to generate, but if it's a constant
strings, it's easier for the other process to recognize it.
It is easy to recognize (comint.
Please don't exaggerate these minor problems.
I'm not saying it's hard. Just that it is easier for people to adapt to
- (if (not (or (eq arg 1) (not arg)))
- ;; if no argument then we guess at hexl-max-address
- (setq max-address (+ (* (/ (1- (buffer-size)) 68) 16) 15))
This removes a special case which seems unused but not uninteresting.
More specifically it hints at a better solution
According to the documentation string, make-frame-visible will Make
the frame FRAME visible (assuming it is an X window).
If the frame is iconized, then make-frame-visible restores it, so it's
visible. But if the frame is just covered by other windows,
make-frame-visible seems to do
isn't it odd to refer to a window you can't see as being visible?
What term do you propose to distinguish between a window which is
displayed but cannot be seen because it's hidden by others, and a window
which is not even displayed?
Stefan
else then I guess it's OK to use that, but isn't it odd to refer to a
window you can't see as being visible? Maybe not. Australia's
Maybe instead of talking about visible we should carefully stick to
visibility and invisible. E.g.
make-frame-visible is an interactive built-in function in
I noticed recently that TRAMP's default connection type has changed
from ssh to scp. Now it's always pestering me for my password.
Me too.
I think we should revert the default to ssh rather than scp: the behavior of
the ssh method is much cleaner/smoother/userfriendly. Its only downside is
a
I think we should revert the default to ssh rather than scp: the behavior of
the ssh method is much cleaner/smoother/userfriendly. Its only downside is
a lesser performance but I think this is a secondary issue.
I what way is it cleaner/smoother/more userfriendly apart from the
password
And I didn't even notice the difference for small files.
That's because your remote host is probably not so remote.
Stefan
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Even venerable od(1) can put *'s in so we don't have to waste screen
space with repeated lines,
0037540
*
0046300 2ff6 0251 094c 0d08 0050 0900 ba2f e87c
0046320 2f80 0251 094c 0d08 0050 0900 ba2f e87c
But does hexl-mode do that?
Not that I know.
ssh-agent solves the problem.
Except when the remote host needs your password to read your
.ssh/authorize_keys, as is the case when this authorize_keys file is on an
NFSv4 partition mounted using Kerberos authentication.
Stefan being there, doing that
I think we should revert the default to ssh rather than scp: the
behavior of the ssh method is much cleaner/smoother/userfriendly.
Its only downside is a lesser performance but I think this is
a secondary issue.
I think the first thing to do is try to fix these bad behaviors.
But does hexl-mode do that?
Not that I know.
What if I want to edit one of the bytes on one of those identical
lines? od is read-only, so it's a good idea to hide identical
lines, but hexl-mode lets me write as well as read, so it's good to at
least have the option of seeing the whole file
However, I had to comment out lazy-lock from my .emacs.
Why? (I mean, it's good that you did, but Emacs should still work just fine
with lazy-lock: i.e. should not have been forced)
I see the .el file is now is lisp/obsolete where it does not get installed
by default,
It does get installed.
I've recently built with mingw, and comint/shell mode doesn't seem to
respond to C-c C-c. I've also tried to invoke the signal using the menu,
no luck. I then tried to invoke using M-x comint-interrupt-subjob, still
no luck.
Most likely the subprocess is a cygwin executable. This is
a
What about if you use ssh-agent? Does that solve the problem?
ssh-agent solves the problem.
So does using these 2 lines:
ControlMaster auto
ControlPath /tmp/[EMAIL PROTECTED]:%p
in ~/.ssh/config, and having an existing ssh connection to the remote
host. Then
`make autoloads' does not process lisp/obsolete, so lazy-lock-mode and
fast-lock-mode do not get autoloaded.
[ Hmm... I guess for some reason it wasn't removed from my loaddefs.el.
Probably because I never bootstrap or something. Looks like a bug in
autoload.el. ]
Indeed you're right.
Except when the remote host needs your password to read your
.ssh/authorize_keys, as is the case when this authorize_keys file is on an
NFSv4 partition mounted using Kerberos authentication.
This is an unusual case, and it's not hard to choose ssh if this
case applies to you.
So the `ssh' method is their best choice until
they change their config,
There's one thing I found very alarming with the 'ssh' method, when I first
used it. I'm used to connecting to a remote machine via ssh, hitting
the up arrow to get back the last shell command I ran, which is
1. Move lazy-lock back out of `obsolete'.
Me don't like it. This package is obsolete and we want to phase it out, so
it should be in `obsolete'.
2. Reenable scanning of `obsolete' for autoloads.
Sounds good.
3. Tell people you must explicitly load `obsolete/lazy-lock'
if you want to keep
Obsolete *autoloaded* packages do not generate any warning on using
them,
That's not true: loading a file from the `obsolete' directory generates
a warning (See the C code of `load'). That warning may pass by too quickly
to be noticed, tho.
Stefan
-(defconst sgml-namespace-re [_[:alpha:]][-_.[:alnum:]]*)
-(defconst sgml-name-re [_:[:alpha:]][-_.:[:alnum:]]*)
+(defconst sgml-namespace-re [_[:alpha:]][-_.[:alnum:]]\\{,64\\})
+(defconst sgml-name-re [_:[:alpha:]][-_.:[:alnum:]]\\{,64\\})
(defconst sgml-tag-name-re
I've recently built Emacs from the 'emacs-unicode-2' branch of the CVS
repository and noticed that some of the fixes that have been made to
the emacs22 pretest version haven't appeared there yet.
We're in the phase of pretest of Emacs-22, so it would be more helpful if
you used that to help us
(nth 9 ppss) is Internal data for continuing the parsing. If we're
going to be using that thing's car as the least nested paren, why
don't we give up the pretence of an internal variable and document it
properly? I know it's used in some other places too, but it seems to
be being economical
[ Expanding on my previous message ]
Could we revert the change to beginning-of-defun instead?
It seems clearly incorrect for beginning-of-defun to ignore
open-paren-in-column-0-is-defun-start.
[ The change I'd like to revert only influences the case where
defun-prompt-regexp is nil so
I disagree in general. What I agree to is that programmers should avoid
putting things that look like defuns inside comments and strings.
Commented-out code may look like a defun.
Indeed, so programmers should be careful to comment out in a way that makes
it not look like a defun. That's
401 - 500 of 725 matches
Mail list logo
