After `(setq display-buffer-reuse-frames t)', `C-h f'(or `C-h v' and the
alike) to view help, `C-x o' to jump to the help window, `q' to quit view
mode, then I find `View-quit' does not restore window and buffer to
previous
state as usual, instead Emacs pops one of other buffers.
Thank you
I've found what I believe to be two bugs in View-quit.
I have two frames visible. In one frame I type: C-h m C-x o C-x 1.
This makes the only window in this frame show the *Help* buffer.
Now I type q, and the frame iconifies.
After C-h m `view-return-to-alist' will contain references for
Please CC this and all related postings to emacs-pretest-bug.
I am not clear about the all the innards of the process of view quit, but
what about:
just let
`help-mode' after (C-h f ...) has done
(setq view-exit-action (lambda (buffer)
(or (window-minibuffer-p
`C-h f' and `C-h v' used to split window and give help information in
another window, why this behavior changed? Now it doesn't split window
anymore and gives help information in a window occupy the whole frame.
Should have been fixed now. Please try again and tell me whether it
works as
Fontset: -*-*-*-*-*-*-*-*-*-*-*-*-fontset-default
Fontset: -*-*-medium-r-normal--10-*-*-*-*-*-fontset-hiraginokaku
Fontset: -*-*-medium-r-normal--12-*-*-*-*-*-fontset-hiraginokaku
Fontset: -*-*-medium-r-normal--14-*-*-*-*-*-fontset-hiraginokaku
Fontset:
with (ido-mode t), emacs complains while C-x C-f:
ad-cache-id-verification-code: Symbol's value as variable is void:
ad-special-forms
Since ido-mode doesn't use advice this has, a priori, nothing to do
with ido (try with Emacs -Q). I suspect you load something in your
.emacs which advices
mode: font-lock
font-lock-defaults: ((^\\S-.*:$))
I must say that I don't know why this has changed.
Does the patch below fix your problem?
No, nothing changed. If I use font-lock-keywords I get the message:
Toggling font-lock-mode off; better pass an explicit argument.
That looks correct:
(set (make-local-variable 'font-lock-keywords)
! (font-lock-eval-keywords (or keywords font-lock-keywords)))
Wouldn't this mean that old keywords survive a major-mode change?
What about the companions in `font-lock-defaults'? In general I
think all those should survive iff they
+(\\(\\)' (1 (sh-font-lock-backslash-quote)))
Then we might do
+(\\(\\) (1 (sh-font-lock-backslash)))
as well.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
shell-script mode thinks everything after the quoted apostrophe is
quoted at least judging from the color.
GNU Emacs 22.0.95.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2007-03-03 on pacem, modified by Debian
#!/bin/sh -ex
test $# -eq 3 ||{ echo $0: couldn\'t look it up in $f
I had this in my local variables section:
mode: font-lock
font-lock-keywords: (^\\S-.*:$)
which worked in Emacs 21, but does not work any more in Emacs 22.
It's a regression though personally I'd avoid placing font-lock
directives in the local variables section and would never permit
if a file has been visited with tramp and sudo
(e.g. /sudo:[EMAIL PROTECTED]:/etc/crontab), and is automatically added to
recentf-list, then `recentf-auto-cleanup' hangs.
Apparently `file-readable-p' (which is in `recentf-keep' by default) is the
reason.
Looks like a bug within
This patch does not work for me.
Because it didn't apply?
I think we should go with the approach suggested by YAMAMOTO
Mitsuharu, which does work. It may not be the most general
approach---as you pointed out, exotic user-set mode lines might cause
failures---but such situations are
Reports from Windows users still wanted.
Works here, thanks.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Reports from Windows users still wanted.
Works here, thanks.
Sorry, no. With a newline after the
html/html
and moving down and back that line I get
sgml-point-entered: Lisp nesting exceeds `max-lisp-eval-depth'
If I define `sgml-point-entered' as
(defun sgml-point-entered (x y)
;;
I could reproduce this, but shouldn't the above `let' be `let*'?
My bad, let*'s ignore this.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
I think it's cleaner to put the condition-case outside. Does this
work for you?
Good. Eventually, someone could try to avoid theses scans when it's
easy to determine that they fail.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Unless someone who is familiar with this matter gives a better one,
I'd propose the following minimal and conservative change to avoid
regression at this stage.
It's too minimal. The following
SET_PT_BOTH (opoint, opoint_byte);
still spoils everything on Windows. Commenting out that
SET_PT_BOTH (opoint, opoint_byte);
still spoils everything on Windows. Commenting out that line works,
though.
Hmm, I couldn't test on Windows, and my previous patch worked on Mac
OS X (both X11 and Carbon) and Solaris for the original problem.
Hence the original problem is present on
This patch works on Mac OS X for the original problem (without my
previous patch). Adding specbind and unbind_to around the
`current_column' in redisplay_internal also works.
I'm still uncertain whether this would catch all occurrences.
The most simple patch I can come up with is
BTW, as far as I can tell, this is a satisfactory permanent solution,
not just a temporary hack; so we might as well check it into the trunk
too. However, we may want to overhaul the way column-number-works,
after the release, to avoid problems of this sort.
Suppose someone wants to put the
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;; move back the cursor
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;;
In GNU Emacs 22.0.990 on Windows, the following operation causes
contiguous redisplay of the menu and beeps. And Emacs doesn't
accept any operations for a while.
emacs -q
M-x html-mode ;; in the scratch buffer
M-x column-number-mode
html/html
C-u 8 C-b ;; move back the cursor on `' of
With `debug-on-error' t you do get an error from `forward-list'?
Yes, but I don't see the not accepting any operations or continuous
redisplay behaviors. Maybe that part of the bug is specific to
Windows.
I think there are three bugs:
(1) The list scanning bug in `sgml-point-entered'. It
This is a change with respect to Emacs 21, and I don't think anyone
feels that it is necessary in practice, while some are against it. I
think it should be reverted.
I think it is just plain wrong to undo a revert.
We could introduce an option `revert-discard-undo'.
;; Declaring and initializing local variables:
-- Declaring and initializing local variables:
These lines are problematic. You should remove the colons, at least,
otherwise Emacs will consider them as start of the local variables
section and search for its end.
ffap-list-directory is nice but it misleadingly gives the same prompt
as dired, Dired file or URL:
You mean the same prompt as dired-at-point. I can offer the
attached patch. Could you try it?
*** ffap.el Sun Apr 8 09:27:20 2007
--- ffap.el Tue May 15 08:27:20 2007
***
Also, I call flyspell-mode in a major-mode hook (or is there anything
wrong with that?), so the error occurs before I even could save it.
I understand.
ispell seems to work around this for synchronous processes, but
apparently not for `start-process'.
I presume both ispell and flyspell
I've tried. From what I can tell `specpdl' isn't being wound back
afterwards, so `save_restriction_restore' is never called.
In fact, this apparently is the case after any error (unless caught by
`condition-case'), so `specpdl' grows bigger and bigger. Is that
supposed to happen??
The
Using this, it was very easy to get the function I wanted.
Calling `syntax-ppss' repeatedly can become costly for deeply nested
positions. I'd propose something like the below:
(defun up-list-forward (arg)
Move forward out of one level of parentheses.
With arg, do this that many times.
A
What happens if you set (customize) `whitespace-check-indent-whitespace'
_before_ you toggle `whitespace-global-mode'?
No difference; sequences of 8 spaces in indentation are still highlighted.
I don't understand. If my .emacs is
(custom-set-variables
;; custom-set-variables was added by
In my Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version
2.10.6) of 2007-04-20 on escher) I see two behaviors:
1. Evalling the above sexp in *scratch* with C-j or in any buffer with
M-: results in what the OP reported: produces a blank frame while the
popup dialog is active, i.e.,
I think for the reason above that it should be buffer local and I also
think that it should be permanent buffer local then.
I think this wouldn't make much sense since `buffer-undo-list' isn't
permanently buffer-local either.
It is, practically speaking. It is
If those calls are done in different buffers it looks like trouble to
me. Should not pending-undo-list be buffer local?
Not by default. If you want to write a function which say, tries to
undo changes simultaneously in two or more buffers in some lock-step
fashion, you can always make it
If I start with -Q and then set whitespace-global-mode to non-nil and
set both whitespace-check-leading-whitespace and
whitespace-check-indent-whitespace to nil, leading sequences of 8 spaces
still get highlighted.
What happens if you set (customize) `whitespace-check-indent-whitespace'
Sorry for not answering earlier but I just retrieved your response from
gmx's spam folder.
So, what is now the recommended way to set file-specific font-lock
keywords using file-local variables? If this has changed, it should be
specified in the NEWS. I can write an entry once I understand
With my recent cvs build or the debian snapshot, and starting from
emacs -Q, visiting the file foo.c below with
C-x C-f foo.c
leaves the first line in the kill ring,
C-y
= inserts /* hello */
where I hoped it would leave the kill ring alone. (In particular it's
not good to
cc-mode doesn't like `line-beginning-position' and
`line-end-position'.
[subr.el]
;; These are the XEmacs names:
(defalias 'point-at-eol 'line-end-position)
(defalias 'point-at-bol 'line-beginning-position)
I think it's for Emacs 20 compatibility.
Here are other incorrect uses of kill-* functions in lisp/progmodes:
cc-cmds.el:859: (kill-region (progn (forward-line 0) (point))
perl-mode.el:653: (kill-region (point) eol))
And there's a bunch of suspicious kill-line/kill-word/kill-region in
mantemp.el and
Please install your patch.
Done.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
# Local Variables:
# mode: indented-text
# fill-column: 95
# mode: font-lock
# font-lock-keywords : (^\\s-*:0 ##+)
# End:
Now, when desktop.el loads it, it asks if I want to apply the
font-lock-keywords customisation, because it is risky (is it?).
The question is asked by
If slime is up and running and M-x slime is called again you are asked if
you
want to start an addtional inferior lisp. If this question is answered with
n
Emacs will crash. The action that triggers the crash is (kill-buffer
*cl-connection*)
Can you reproduce the bug with the attached (100%
In a buffer with scheme-mode active, delete-trailing-whitespace treats
a traling vertical bar character (|) as trailing whitespace (that is,
the character is deleted when invoking delete-trailing-whitespace,
either interactively or as a write hook). Other modes (elisp, lisp, c,
fundamental) seem
Now that I think about it, I realize that many Emacs users have not studied
the advanced mathematics where they would encounter the term iff.
So I think it is better to avoid that term.
(I was the one who introduced it into Emacs doc strings.)
I have added this to TODO for fixing post-22
edebug-pop-to-buffer changes the buffer in the next window.
However this results in an error, if that window is dedicated.
Please try the attached patch.
*** edebug.el.~3.96.~ Mon Apr 2 07:45:10 2007
--- edebug.el Thu Apr 12 09:06:24 2007
***
*** 364,389
(defun
I set it in custom-set-variables; another likely scenario, I would think.
whitespace.el has this form
(defcustom whitespace-check-indent-whitespace indent-tabs-mode
which, as Miles explained, gets evaluated when whitespace is loaded with
the value `indent-tabs-mode' has at that time.
(defcustom whitespace-check-indent-whitespace indent-tabs-mode
Flag to check indentation whitespace. This is the global for the system.
That fails to do the right thing if the user changes indent-tabs-mode
mode after whitespace.el is loaded -- which is certainly not unlikely,
especially
I'm using the emacs-unicode-2 branch. After a recent update of my
working copy, whitespace-auto-cleanup replaces sequences of 8 spaces in
leading whitespace with tabs. It does this even though indent-tabs-mode,
whitespace-check-leading-whitespace, and
whitespace-check-indent-whitespace are
emacs-22.0.90 -Q
c-xc-f /etc/termcap
c-xc-q To make it writable
c-kc-kc-y kill the first line and put it back.
It will not do it without this line kill
c-s thedo this until you leave the first screen displayed. This will
recenter the buffer on the the found.
Why not do this as with `isearch-allow-scroll' t? I don't know
server.el, maybe something flashy like ...
(cond
((minibufferp))
((buffer-local-value 'isearch-mode (current-buffer))
(let ((isearch-point (point))
(new-window (split-window)))
;; ... do the server-switch-buffer
What do you think it should do in such a case,
where scrolling happens validly and correctly
(and you expected it)
while mouse-1 is held down?
If mouse did not move? A click.
For a click you have to find a POS-OR-AREA:
This is the buffer position of the character clicked on in the text
PC-do-complete-and-exit: Wrong type argument: char-or-string-p, t
Thanks for reporting. Should have been fixed in the meantime.
Please try again.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
package abbrev can't be required.
abbrev is preloaded. Why do you see a need to require it?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Interesting. It might be a bit harder in this case though, because you can
have an apostrophe at the end of a word, e.g, two mens' sons, meaning the
sons of two men. So you would also have to check for an apostrophe at the
start of the word.
.. or a back-quote, as in `kill-word' -- but what
This is not correct, because it seems to leave buffer-undo-list
permanently set to t. That prevents undoing of changes made by hand
by the user.
Locally binding `buffer-undo-list' around the `erase-buffer' in
`occur-1' is trivial. But `occur-mode' has this
(add-hook
Emacs turns off undo data generation while computing the *occur* buffer:
(defun occur-engine (regexp buffers out-buf nlines case-fold-search
title-face prefix-face match-face keep-props)
(with-current-buffer out-buf
(let ((globalcount 0)
;;
The attached patch uses brute force.
*** replace.el Fri Feb 23 07:56:32 2007
--- replace.el Mon Feb 26 11:40:36 2007
***
*** 739,744
--- 739,745
(use-local-map occur-mode-map)
(setq major-mode 'occur-mode)
(setq mode-name Occur)
+ (setq buffer-undo-list t) ;
Because your model of what happens is incorrect. The menu is
processed in its entirety by the Windows menu-handling API, and Emacs
never sees anything until the menu is popped down.
In Lennart's example there are _two_ menus. The one popped by
`temp-test1' and the other popped by
How do you continue to interact with the menu after toggling the menu item?
I lied: The toggle is specified in a function `speck-menu-tail' as
...
---
[Query-replace 'query
:style toggle :selected speck-replace-query
:help Replace this and query for further occurrences.]
I think the following patch should be applied to ispell.el (but I don't
use polish).
What bug is this trying to fix?
In English you use the regexp ['] to match any ' embedded in a word
like don't. In Polish . would match _any_ character embedded in a
word. Simply noticed by
I think the following patch should be applied to ispell.el (but I don't
use polish). The regexp in francais7 is not wrong but misleading.
*** ispell.el.~1.203.~ Mon Nov 6 10:23:02 2006
--- ispell.el Fri Jan 12 11:47:16 2007
***
*** 574,580
[A-Za-z^\\] [^A-Za-z^\\]
In Emacs 22 evaluate:
(setq myvar '((0) (1) (2) (3) (4) (5) (6) (7) (8) (9)))
(make-local-variable 'myvar)
(setq myvar 1)
then do C-h v myvar RET.
Help buffer output:
[...]
Note the local value of 1 is not shown.
Would the below break anything else?
*** help-fns.el.~1.94.~ Sun Dec
There's something screwy about word boundries in wdired mode. Say I
have the following files in a directory:
FOO.EXT
BAR.EXT
BAZ.EXT
If I try to downcase them by placing point on F and hitting M-l a
number of times, then I end up with this:
foo.ext
BAR.ext
BAZ.ext
The first two
This does indeed fix it. I suggest it be installed even if it's
somewhat suboptimal.
I still have to learn how to install patches.
Anyway, if people think that this patch is sufficient, the doc strings
and manual entries for `downcase-word', `upcase-word', `capitalize-word'
should explain
flyspell-buffer runs much longer than flyspell-region, except for
regions 1,$ (line 1 to EOF) and 2,$ whereupon I also have to kill it
with ^G. Region 3,$ is OK.
$ wget http://jidanni.org/abj/articles/20061230.html
$ LC_ALL=C LANG=C emacs -Q 20061230.html
flyspell-buffer
emacs-snapshot
Usually with :entry-format and :format.
No special formatting should be necessary, just to be able to use a simple
tag. I don't believe that was why :*format were introduced.
You would have to specify what a simple tag is in the first place.
Formatting tags is for handling non-standard cases
So? Bug reports about customization don't concern such users, so ignore them
in the present context. If you don't care about customization either, then
perhaps someone else should respond to this bug report. I do care about
customization, and that's why I reported the bug.
Sorry. I herewith
emacs -Q
M-x customize some-group
The options and faces should be in alphabetical order. The actual
order seems random.
Should be possible:
(defcustom custom-browse-sort-alphabetically nil
If non-nil, sort members of each customization group alphabetically.
:type 'boolean
:group
When a value menu is present, the current value should be on a
separate line from the Value Menu button. Currently, the current value
is listed next to the Value Menu button, which makes the Customize
buffer far too wide.
The author of an option is responsible for its appearance.
Tags for
Thx - I wasn't aware of those.
However:
- They are apparently not autoloaded, so `C-h v' doesn't recognize them
until customize has been loaded.
How can `C-h v' help you to find something you're not aware of?
- None are mentioned in the Emacs manual (or the Elisp manual, for that
When a value menu is present, the current value should be on a
separate line from the Value Menu button. Currently, the current value
is listed next to the Value Menu button, which makes the Customize
buffer far too wide.
The author of an option is responsible for its appearance.
Uh,
BTW, in Elisp an open bracket in column zero of a string should not
confuse Emacs. Yet you highlight it with `font-lock-warning-face'.
Indeed, it *shouldn't*, but it does confuse Emacs, which is why it's
highlighted ;-(. We should fix it so it doesn't confuse Emacs any more (and
doesn't
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.
I.e. in Lisp, an open-paren-in-col0 is indeed a bad idea. In C it's not
a problem (maybe an
One problem I found is that it allows me to edit the last space in the
- string that indicates a symbolic link.
If I have a symbolic link a - b in the directory I'm editing, I can
delete the 2nd space, leaving a -b, and when I hit C-c C-c, I end
up with a - /dev/null.
These doc strings don't describe the position of the variable well:
The variable-at-point doc string mentions nothing about using a
variable near point - it says only around point, which suggests that
only a variable at point is used. The find-variable doc string
mentions using a variable
Here's a tentative fix for the bug, not that well tested, but tested a
little bit:
2006-12-04 Alan Mackenzie [EMAIL PROTECTED]
* emacs-lisp/lisp.el (beginning-of-defun-raw): In the seeking a
non-nested open-paren case, check there are enough lists to move
over. Return the
6. In any case, the new behavior should be documented since it applies
whenever `open-paren-in-column-0-is-defun-start' is set to nil.
Where are documentation changes are needed for this?
In the Elisp description of `beginning-of-defun' I presume. I'd explain
the following issues:
Evening, Martin!
Evening, Alan!
1. You don't widen the buffer before calling `syntax-ppss'.
You mean I don't have to, and would get the same result without
widening? I need to widen anyway, in case point is inside a
comment/string and (point-min) is after the c/s's start.
No, I mean you
I see this too a lot, even in plain C files. A backtrace when this
happen looks like this:
Debugger entered--Lisp error: (scan-error Containing expression ends
prematurely 107612 107612)
scan-lists(107699 -1 0)
forward-list(-1)
backward-list(1)
beginning-of-defun-raw(nil)
The patch at
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01071.html no
longer applies cleanly to the wdired.el in CVS, even after correcting
the wrapping of long lines and ignoring white space. The patch is
also really quite large.
It is large because it also tries to handle
In wdired I can replace the space before the filenames during
query-replace with a character. It doesn't seem to cause anything,
it just doesn't look good.
I think it's a bug:
The only editable texts in a WDired buffer are filenames,
symbolic link targets, and filenames permission.
Please
These days flyspell-auto-correct-word seems to always take three
invocations to correct a word. First always giving two dumbo choices
similar to this sequence:
0. accross
1. ac cross
2. ac-cross
3. across
The choices are provided by ispell / aspell, flyspell can't do much
about that.
I've just noticed that you added
(overlay-recenter (point-max))
to `remove-overlays'. That might cause a slowdown if you remove
overlays near bob and there are many overlays between the ones you
remove and eob. Please consider replacing this by
(overlay-recenter end)
after the value of
Should be fixed now.
Thanks for correcting my mistake.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
So, if I understand you correctly, the change to make is to replace
(remove-overlays nil nil 'face 'whitespace-highlight)
(overlay-recenter (point-max))
with
(overlay-recenter (point-max))
(remove-overlays nil nil 'face 'whitespace-highlight)
Is that right?
Right.
and w32menu.c.
My problem is that `menu-or-popup-active-p' should return nil even in
the case where you build without menus. Hence I propose the attached
patch. Please try whether it works on your system.
Thanks again
martin rudalics.
*** macmenu.c Mon Nov 6 10:23:06 2006
--- macmenu.c Mon Nov 6
If you've found a slowness in remove-overlays, could you aim to make
that function faster, rather than making its caller faster by not using
remove-overlays?
Using `remove-overlays' to delete all overlays with a given property is
overkill. The tests
(if ( (overlay-start o) beg)
I tried M-: (remove-overlays nil nil 'face 'whitespace-highlight) and
it took about the same time what was the increment between first and
other runs. Evaluating it when point is at bottom, very fast, but when
point is at top, it is slow.
I think you can easily test it by making slowtst.el
Thanks for your prompt answer!
Yes, with this last fix finally whitespace-buffer seems to be quite
fast each time.
Thanks for you cooperation. Please keep an eye on this.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
Interesting things again! I tried this latest whitespace.el and found
the followings:
1. whitespace-buffer on slowtst.el takes ~9 seconds (=the same result
what I got with your previous fix) IF point is at the beginning of the
buffer. If point is somewhere down (e.g. at (point-max))
Attached find patch and ChangeLog entry for this.
* whitespace.el (whitespace-indent-regexp): Make this match any
multiples of eight spaces near the beginning of a line.
(whitespace-buffer): Use `remove-overlays' instead of
`whitespace-unhighlight-the-space' to
What shall I check exactly here? I ran this white() and yes, it
finishes in 1-2 seconds. However I also ran (M-:)
(whitespace-buffer-search whitespace-ateol-regexp) and it also took
1-2 seconds on my problematic original source file (it has only one
eol error).
However with my slowtst.el I
With symbol-at-point however, I intend to drop the
(if thing (intern thing))
form when called.
FWIW, the `intern' call has been inserted around July/August 2006 but I
couldn't find a suitable ChangeLog entry. Stefan did you write that?
___
[...]
1.36 (monnier 04-Jul-06): (if thing (intern thing
[...]
and `L' prints the same entry as in lisp/ChangeLog:
,[ lisp/ChangeLog ]
| 2006-07-04 Stefan Monnier [EMAIL PROTECTED]
|
| * thingatpt.el (symbol-at-point): Don't use `form-at-point' which
| fails if
Try C-x v ~ 1.35 to see the code before my change (or try C-x v = to
see the diff between 1.35 and 1.36). You'll see that the previous code
returned a symbol, not a string.
Silly me. I stubbornly decided the previous code returned a string
built from word and symbol constituents. Apologies
It looks like we could speed it up even more
by producing this list
! (setq whitespace-retval (cons (match-beginning 0)
whitespace-retval))
only if it is actually wanted. Calling from whitespace-buffer
could pass t as an optional argument saying do produce this list.
We could
I forgot to say that I can't follow Peter's argument that older 2006 Emacsen
didn't have this problem. I tried with a couple of versions starting with a
mid-2005 one and all exhibited the same behavior as the most recent one.
___
emacs-pretest-bug
Seems as function `list-at-point' from thingatpt.el
fails.
Currently `list-at-point' does `up-list' followed by `backward-sexp'
followed by another `up-list' which doesn't make sense. Please look at
the attached - largely untested - patch which also tries to handle the
problem that
We could define `find-function-regexp' as:
(defcustom find-function-regexp
;; Match things like (defun foo ...), (defmacro foo ...),
;; (define-skeleton foo ...), (define-generic-mode 'foo ...),
;; (define-derived-mode foo ...), (define-minor-mode foo)
(concat
1 - 100 of 162 matches
Mail list logo
