headers
Paul Pogonyshev | 1 Jul 2003 05:16
Picon

Re: strange behaviour of `isearch-forward-regexp'

I wrote:
> While searching for " ?t" regular expression, letter 't' in word
> "reset" doesn't match.  This is very strange since searching for
> "t?t" and even "^I?t" does match the letter.  Is it "a feature"
> or a bug somewhere in Emacs?

Kevin Rodgers wrote:

> It's a feature, though it doesn't appear to be documented in the Emacs manual:
>
> | search-whitespace-regexp's value is "\\s-+"
> |
> | Documentation:
> | *If non-nil, regular expression to match a sequence of whitespace chars.
> | This applies to regular expression incremental search.
> | You might want to use something like "[ \t\r\n]+" instead.
> | In the Customization buffer, that is `[' followed by a space,
> | a tab, a carriage return (control-M), a newline, and `]+'.
>
> You need to type `C-s C-q SPC ? t', or set search-whitespace-regexp to nil.

Wouldn't it solve the problem if `search-whitespacec-regexp' was set
to "\\(\\s-+\\)" by default?  Or would it break something match group
related?

And, btw, i'm not subscribed to the list.  Could you please CC answers
to me?

Paul Pogonyshev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Allen Everhart | 1 Jul 2003 02:36

forward-char on vt100 w. emacs v. 21.3.1on linux (RAS 2.1)

Hi, this has been driving me crazy.
 

forward-char on vt100 w. emacs v. 21.3.1on linux (RAS 2.1)

Every 7 or 8 forward-chars in emacs results in the next 4 characters of text being blanked out. I can work around by redisplaying the screen by typing ctrl-l but that gets tedious. I think this may have something to do with tab-stops which also have about the same periodicity and the bad behaviour occurs only on columns whose number is one less than a multiple of 8 (i.e. 7, 15, 23) . When I put my terminal emulator in display-controls mode I see that what is output is 4 blankspaces followed by a backspace. This behaviour does not manifest in any other character cell application (e.g. vi) It also expresses the same way using other terminal emulators.
 
 
Please help - I can't stand vi but see no good alternative.
 
Best.
 
-Allen
 
 
_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs <at> gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
Permalink | Reply | 0 comments |
headers
Mark Evenson | 24 Jul 2003 14:04
Picon
Favicon

Re: [BUG] emacs cygwin compile.el next-error fails with Ant

Following the suggestion of Joe Buehler the following scripts placed in
$HOME/bin, with ant-emacs chmod'd to execute

ant-emacs
----------------------------------------------------------------------
#!/bin/sh
ANT_ARGS="$ANT_ARGS -emacs" 
ANT_OPTS="$ANT_OPTS -Dbuild.compiler.emacs=true" 
export ANT_ARGS ANT_OPTS
ant $* 2>&1 | gawk -f $HOME/bin/transform.gawk 2>&1 | sed s/\\r//g | sed s/^gawk.*$//
----------------------------------------------------------------------

and the following gawk script 

transform.gawk
----------------------------------------------------------------------
/^[A-Z]:/ {
      command = "tr \\\\\\\\\ / | xargs cygpath "; 
      printf "%s", $1 | command;  
      close(command); 
      for (i = 2; i < NF; i++) {
        printf " %s", $i;
      };
      printf "\n";

      next;
}
{print}
----------------------------------------------------------------------

will make next-error work in compile.el with Emacs running under cygwin.
This is not perfect, as it changes the output slightly (I have a extra
newline emitted somehow), but it might help someone else.

After some investigation and further reflection, I think this can be
classified as a problem with Ant, and not with cygwin and/or Emacs as Ant
should emit "UNIX normalized" pathnames if it is running under
cygwin/Emacs.  The problem with implementing this is that Ant is merely
passing back the output from a native win32 javac which necessarily needs
the platform dependent path.separator variable.  Maybe I will have time his
weekend to look into this.

--

-- 
Mark Evenson <evenson <at> panix.com>

"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."
Permalink | Reply | 0 comments |
headers
Joe Buehler | 24 Jul 2003 16:05

Re: [BUG] emacs cygwin compile.el next-error fails with Ant

Mark Evenson wrote:

> /^[A-Z]:/ {
>       command = "tr \\\\\\\\\ / | xargs cygpath "; 
>       printf "%s", $1 | command;  
>       close(command); 
>       for (i = 2; i < NF; i++) {
>         printf " %s", $i;
>       };
>       printf "\n";
> 
>       next;
> }
> {print}

I think I see now why you said that my posted command would not work.
The problem is that I have not yet fixed emacs to recognize drive letters.
The workaround is to use the /cygdrive/DRIVELETTER syntax.

So try something like this:

ant whatever 2>&1 | sed 's=\\=/=g;s=\([a-zA-Z]\):/=/cygdrive/\1/=g;s/\r//g'

This:

1. changes \ to /
2. changes X:/ to /cygdrive/X/
3. removes carriage returns

I saw you used some GNU sed feature for 3, so correct it if I got it wrong.
I don't think it's portable to other platforms so I never use it.
--

-- 
Joe Buehler
Permalink | Reply | 0 comments |
headers
Jonathan Kamens | 28 Jul 2003 03:33
Picon
Gravatar

Re: unrmail

Kevin Rodgers <ihs_4664 <at> yahoo.com> writes:
>The Received: header added by the local MTA would be even closer to
>the time the message was actually delivered.

True, but it's not worth the effort to parse the Received: header, whic
his in a relatively free-form format -- the Date: header is good
enough, especially since, as you point out, very little software
actually uses the date in the From_ line.  What I'm objecting to is not
even trying *that* hard to put a useful date in the From_ line.
Permalink | Reply | 0 comments |
headers
Glenn Morris | 28 Jul 2003 20:00
Picon
Picon
Favicon

Re: [PATCH]saveplace.el: forget saved places for unreadable files

Richard Stallman wrote:

> This suggests it would be useful to add a feature for specifying
> patterns of file names that should not be tested. Perhaps there can
> be a default pattern that matches all remote file names, etc. Then
> the feature could be enabled by default. What do you think?

Just a comment that recentf.el has some code that tries to deal with
this issue - see the `*cleanup*' symbols. At the moment, it just
checks for readability and a user-specified exclude regexp. It would
be nice if the two implementations ended up being consistent, seeing
as how they do essentially the same job.
Permalink | Reply | 2 comments |
headers
Keiichi Suzuki | 30 Jul 2003 04:25
X-Face

printify-region

`printify-region()' ends conversion before the expected
position.

A patch from the CVS HEAD is following.

-------- 8>< -------- 8>< -------- 8>< -------- 8>< --------
Index: lpr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/lpr.el,v
retrieving revision 1.63
diff -u -u -r1.63 lpr.el
--- lpr.el	4 Feb 2003 11:34:44 -0000	1.63
+++ lpr.el	30 Jul 2003 02:14:56 -0000
 <at>  <at>  -283,14 +283,16  <at>  <at> 
 The characters tab, linefeed, space, return and formfeed are not affected."
   (interactive "r")
   (save-excursion
-    (goto-char begin)
-    (let (c)
-      (while (re-search-forward "[\^ <at> -\^h\^k\^n-\^_\177-\377]" end t)
-	(setq c (preceding-char))
-	(delete-backward-char 1)
-	(insert (if (< c ?\ )
-		    (format "\\^%c" (+ c ? <at> ))
-		  (format "\\%02x" c)))))))
+    (save-restriction
+      (narrow-to-region begin end)
+      (goto-char (point-min))
+      (let (c)
+	(while (re-search-forward "[\^ <at> -\^h\^k\^n-\^_\177-\377]" nil t)
+	  (setq c (preceding-char))
+	  (delete-backward-char 1)
+	  (insert (if (< c ?\ )
+		      (format "\\^%c" (+ c ? <at> ))
+		    (format "\\%02x" c))))))))

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;; Functions hacked from `ps-print' package.
-------- 8>< -------- 8>< -------- 8>< -------- 8>< --------
--

-- 
Keiichi Suzuki / keiichi <at> nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4  4089 7AAF 2B03 ECBD 614B
Permalink | Reply | 0 comments |
headers
Frederik Fouvry | 30 Jul 2003 17:19
Picon

global-font-lock-mode

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-08-29 on astest
configured using `configure  --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefiix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-gcc
--with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: de_DE <at> euro
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

After loading pcvs.el, the variable global-font-lock-mode is for
Emacs defined in pcvs-info.el (shown by C-h v
global-font-lock-mode RET in the buffer *Help*).  In *Help*
however, it cannot find the definition in pcvs-info.el (by
clicking on "Defined in `pcvs-info'." at the end of the buffer):
is says:

Cannot find definition of `global-font-lock-mode' in library
`pcvs-info'

Actually global-font-lock-mode is defined for a second time in
pcvs-info.el: (from emacs/21.2/lisp/pcvs-info.el):

----------------------------------------------------------------------
(defvar global-font-lock-mode)
(defvar font-lock-auto-fontify)
(defcustom cvs-highlight
  (or (and (boundp 'font-lock-auto-fontify) font-lock-auto-fontify)
      (and (boundp 'global-font-lock-mode) global-font-lock-mode))
  "*Whether to use text highlighting (à la font-lock) or not."
  :group 'pcl-cvs
  :type '(boolean))
----------------------------------------------------------------------

Originally it came from loaddefs.el (and from font-lock.el).

The error message is confusing because of two reasons:
- there _is_ a definition in pcvs-info.el
- the real definition is in loaddefs.el (and coming from font-lock.el).

Given the boundp() test on global-font-lock-mode, I don't see why
defvar() is still necessary.  Perhaps for compilation, but then

(eval-when-compile (require 'font-lock-mode)) 

would solve that.  The variable would only be defined once, and then
it would be found properly from *Help*.

(Probably the same is true for font-lock-auto-fontify, but that's
XEmacs.)

Recent input:
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <mouse-movement> 
<mouse-movement> <mouse-movement> <drag-mouse-1> <down-mouse-1> 
<mouse-1> <switch-frame> <switch-frame> <help-echo> 
<help-echo> <help-echo> <down-mouse-1> <mouse-1> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu> 
<report-emacs-bug>

Recent messages:
Scanning buffer for index ( 55%)
Scanning buffer for index ( 74%)
Scanning buffer for index ( 88%)
Scanning buffer for index (100%)
Mark saved where search started
byte-code: Buffer is read-only: #<buffer pcvs-info.el>
Mark saved where search started
Mark set
Mark saved where search started
Loading emacsbug...done
Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 30 Jul 2003 23:04
Picon
Favicon

M-x checkdoc complains about -*- line

In GNU Emacs 21.3.1 (i386-pc-solaris2.7, X toolkit)
  of 2003-04-24 on briard
Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: nil
   locale-coding-system: nil
   default-enable-multibyte-characters: t

The presence of an initial line like

;;; -*-unibyte: t;-*-

causes `M-x checkdoc' to complain

	There is no first line summary!  Add one? (y or n)

even though the next non-blank line is

;;; goto-last-change.el --- Move point through buffer-undo-list positions

--

-- 
Kevin Rodgers
Permalink | Reply | 0 comments |
headers
Bjoern Milcke | 31 Jul 2003 09:52
Picon

21.3: end-of-buffer resets mark

Hi,

Title:  `end-of-buffer' resets mark.
------------------------------------

Description:
------------

Do the following:

1. `set-mark-command'         (C-SPC)
2. `next-line'                (down)
3. `end-of-buffer'            (C-end, non-standard key?)
4. `exchange-point-and-mark'  (C-x C-x)

=> you will notice that the mark is at the point from where you
   called `end-of-buffer' and not the line above where you called
   `set-mark-command'.

,----[ C-h f end-of-buffer ]
| end-of-buffer is an interactive compiled Lisp function in `simple'.
| (end-of-buffer &optional ARG)
| 
| Move point to the end of the buffer; leave mark at previous position.
| With arg N, put point N/10 of the way from the end.
| 
| If the buffer is narrowed, this command uses the beginning and size
| of the accessible part of the buffer.
| 
| Don't use this command in Lisp programs!
| (goto-char (point-max)) is faster and avoids clobbering the mark.
`----

Does 'leave mark at previous position' mean set it to the current
point when calling?  If so, why is this implemented this way?  Or
how could it be done differently?

Information:
------------

Emacs: GNU Emacs 21.3.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll
bars) of 2003-03-24
OS: Linux 2.4.19-4GB #1 Fri Sep 13 13:14:56 UTC 2002 i686 unknown

Question:
---------

Where can I look, whether bugs are already known (Issuezilla or the
like)?

-Bjoern

--

-- 
Bjoern Milcke                   mailto:Bjoern.Milcke <at> Sun.COM
Software Engineer               http://www.sun.com/staroffice
(Star|Open)Office Chart         http://graphics.openoffice.org
Permalink | Reply | 0 comments |

Gmane