headers
John Kodis | 1 Jan 2003 19:38
Picon

Local variable "mode" breaks hide-show mode

In GNU Emacs 21.2.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-08-28 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-prefix=/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: 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: en_US
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

I enabled the hide-show minor mode and the automatic hiding of any
initial comment block by creating a .emacs file containing only:

(add-hook 'c-mode-common-hook
 '(lambda ()
    (hs-minor-mode)
    (hs-hide-initial-comment-block)))

When editing the following C program (program fragment really -- I
deleted all the irrelevant bits to better explore the problem), the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Jacobson | 2 Jan 2003 00:11

C-s C-s... with no previous string

Maybe emacs should say something if no previous string is known:
$ emacs
C-s C-s [C-s...]

At it is it feels like one has hit XOFF :-)
--

-- 
http://jidanni.org/ Taiwan(04)25854780
Permalink | Reply | 1 comment |
headers
Lyndon Nerenberg {VE6BBM} | 2 Jan 2003 02:08
Picon
Picon

etags -f /dev/stdout enhancement request

etags treats "-f -" as a special case in that the pathname of the
source file is not made relative to the location of the tags file.
Specifying "-f /dev/stdout" defeats this check, resulting in bogus
source file pathnames in the tags file. Enclosed is a patch that causes
"-f /dev/stdout" to be treated the same as "-f -" is.

This diff is against the 21.2 released sources.

===================================================================
RCS file: lib-src/etags.c,v
retrieving revision 1.1
diff -u -r1.1 lib-src/etags.c
--- lib-src/etags.c     2003/01/02 00:49:42     1.1
+++ lib-src/etags.c     2003/01/02 00:50:44
 <at>  <at>  -1094,6 +1094,10  <at>  <at> 
       cwd = concat (oldcwd, "/", "");
       free (oldcwd);
     }
+  if (streq (tagfile, "/dev/stdout"))
+    {
+      tagfile = "-";
+    }
   if (streq (tagfile, "-"))
     tagfiledir = cwd;
   else
Permalink | Reply | 0 comments |
headers
Dan Jacobson | 2 Jan 2003 01:55

dabbrev-expand wiped out newline

The effects of my C-o are wiped out typing
C-n C-n C-n C-n C-n C-n C-n C-o # ESC /
for this file (I wanted to add a forth "---" line).
#-----------------------------------------------
if
	$h_subject: contains $n9
  then
	logwrite "wow"
	seen finish
endif
#-----------------------------------------------
if
	$h_X-Spam-Status: contains FROM_NO_USER
then
 logwrite "FROM_NO_USER spam: $tod_log $h_from $h_subject"
 fail "Looks like FROM_NO_USER spam"
 seen finish
endif
#-----------------------------------------------
Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 2 Jan 2003 19:16
Favicon

Re: C-s C-s... with no previous string

Dan Jacobson wrote:

> Maybe emacs should say something if no previous string is known:
> $ emacs
> C-s C-s [C-s...]
> 
> At it is it feels like one has hit XOFF :-)

I agree.  Here's one way to do it:

*** emacs-20.7/lisp/isearch.el.orig	Wed May 31 05:43:30 2000
--- emacs-20.7/lisp/isearch.el	Thu Jan  2 11:12:27 2003
***************
*** 906,912 ****
   		(or (if isearch-regexp
   			(car regexp-search-ring)
   		      (car search-ring))
! 		    "")
   		isearch-message
   		(mapconcat 'isearch-text-char-description
   			   isearch-string ""))
--- 906,915 ----
   		(or (if isearch-regexp
   			(car regexp-search-ring)
   		      (car search-ring))
! 		    (progn
! 		      (message "Search ring is empty")
! 		      (sleep-for 1)
! 		      ""))
   		isearch-message
(Continue reading)

Permalink | Reply | 0 comments |
headers
tytso | 2 Jan 2003 21:48
Picon
Picon
Favicon
Gravatar

Suggested enhancement: allow emacsclient to send arbitrary LISP expressions


This patch allows the emacs client to pass in an arbitrary lisp
expression, which will be executed by the emacs server process.  

For example: emacsclient '(make-frame-on-display "localhost:12")'

The patch is fully backwards compatible with older versions of
emacsclient, since emacsclient always sends absolute pathnames to the
emacs server.  The leading open parenthesis is used to indicate that
string is a lisp expression which should be evalulated.

On the emacsclient side, currently we simply use a leading open
parenthesis to indicate that the argument is a LISP expression.  This
means that attempts to edit a file that begins with an open expression
will now be interpreted as a LISP expression.  In practice I don't
expect this to be a problem, although if this is a major concern, a
option such as --lisp could be added to emacsclient to inhibit adding
the absolute pathname to the argument, instead of always treating
arguments that begin with an open parenthesis as LISP expressions.

Note: If I were designing the emacsclient/emacsserver protocol all
over again from scratch, emacsclient would always pass s-expressions
which would be intepreted as lisp expressions by the emacs process.
This would eliminate the current kludgy, ad-hoc quoting that
emacsclient uses.

						- Ted

--- emacsclient.c	2003/01/02 19:33:41	1.2
+++ emacsclient.c	2003/01/02 19:34:43
(Continue reading)

Permalink | Reply | 20 comments |
headers
John Bartelt | 3 Jan 2003 00:36
Picon
Favicon

Re: buidling emacs 21.2 on solaris 7 or later

PPS: Maybe the problem is both 'string.h' and 'stirngs.h' are
included.

Here is the error message from gcc:

bartelt <at> www5 $ gcc -c   -I/usr/openwin/include    -g -O  -DEMACS_BITMAP_FILES 
-DHAVE_CONFIG_H -Demacs -I. -I../src 
-I/afs/slac.stanford.edu/package/emacs/build/emacs-21.2/lwlib 
-I/afs/slac.stanford.edu/package/emacs/build/emacs-21.2/lwlib/../src xlwmenu.c
In file included from /usr/openwin/include/X11/Xos.h:81,
                 from xlwmenu.c:32:
/usr/include/strings.h:25: conflicting types for `memmove'
/usr/include/string.h:44: previous declaration of `memmove'
/usr/include/strings.h:26: parse error before `0'
/usr/include/strings.h:26: warning: conflicting types for built-in function 
`memset'

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
John Bartelt                             bartelt <at> SLAC.Stanford.edu
Stanford Linear Accelerator Center       650-926-4591
MS 97, P.O. Box 4349                     
Stanford, CA 94309                       office:  SCS room 380
Permalink | Reply | 0 comments |
headers
John Bartelt | 3 Jan 2003 00:31
Picon
Favicon

buidling emacs 21.2 on solaris 7 or later

Hello.  I have recently run into a new problem building emacs 21.2
on solaris 7, 8, 9.  The problem may be Sun's fault, but I thought
I would run it past you first.

I had successfully built emacs 21.2 on solaris 7 twice in 2002.
In December, I tried to build it again (same computer, same version
of gcc).  But the build failed in the lwlib directory (see below).
I traced this new problem to a change in an openwin include file,
X11/Xos.h.  It was changed by Sun's patch 108376-36.  If I edit
xlwmenu.c to use the older version of this file, the build succeeds
completely.  If I use the newer patched version, the build fails
100% of the time, independent of the compiler version (cc or gcc).

These details are specific to solaris 7; but the build fails in the
same way on solaris 8 and 9.  The patch numbers may be different.

I am not sure if its possible to workaround this in the ./configure
script.  I did not find any set of switches that would make it work.
Maybe it is purely a Sun/Openwin problem.

John Bartelt

PS:  Here is the output from the failing compilation:

cc -c   -I/usr/openwin/include    -g -O  -DEMACS_BITMAP_FILES -DHAVE_CONFIG_H 
-Demacs -I. -I../src 
-I/afs/slac.stanford.edu/package/emacs/build/emacs-21.2/lwlib 
-I/afs/slac.stanford.edu/package/emacs/build/emacs-21.2/lwlib/../src xlwmenu.c
"/usr/include/strings.h", line 25: identifier redeclared: memmove
        current : function(pointer to void, pointer to const void, uint)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel "Kjøller" Skovenborg | 3 Jan 2003 00:58
Picon
Favicon
Gravatar

syntax highlighting problems when using strings

Hello Emacs-people

I have experienced problems when dealing with string
in c++-mode (the problem might exist in other modes as
well, but I haven't tested). 

The following string (I replaced the text, but not the
characters that might cause the problem) make the
following many lines higlighted as string.
"bla blajlka a alkjalk af lakjfla sdlk alkfajlajf
aljs\
aslkkjsal aslfkjaslkjsdflkkjajoiejfoiv\
f s sdlfj \"sflka\" ljalk flksdlksd f \
lsd dfslk\'t sdflkjsdflkjfsd sdflkdfs\
sflkjsdflk salkdfj sdfl sdflkj d\
asflkjsdf klsdfj sdfklj lksdfj lksfj fs"

It seems that Emacs doesn't deal properly with
multiline shift in highlighting. The problem occurs
when you make a " to start a string and the rest of
the buffer gets highligted as text (wich is OK) and
then ends the string. The syntax highlighting isn't
always updated at once and sometimes never. I have
experienced the same problem with /* */ commenting.

Yours sincerely
Daniel Kjøller Skovenborg

P.S.: Emacs will always be better than vi, no matter
how many bugs it has (but fix them anyway).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Slaven Rezic | 3 Jan 2003 02:32
Picon

browse-url and galeon

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 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'
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: C
  value of $LANG: de_DE.ISO-8859-1
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: nil

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

I use galeon as standard browser for browse-url by using the following
lines in my .emacs:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane