Splash-screen, elisp files compression, gdb usage

[ESCOUFLAIRE Pierre-Louis]

Hello,

While using emacs-22.1, I found the following problems:

  1- splash-screen '(setq inhibit-startup-message nil)':
      . calling emacs (no arguments):
          A splash-screen appears, which is perfectly normal.
      . calling emacs <filename>:
          A splash-screen appears, which is a regression from emacs-21.
          emacs waits for an input event to open associated buffer.

THIS IS NOT A BUG but RATHER A SUGGESTION.
I think that users requesting a file expect that file to be opened 
directly without having the splash-screen. I know that setting the 
'inhibit-startup-message' to 't' will avoid this problem but some 
configuration are using this splash-screen and can be annoying in 
certain cases (such as loading an elisp diff script in emacs from 
command line).
Newcomers to emacs are generally using 'emacs' with no arguments on 
their first use of it so they would see the splash-screen. Plus, they 
still can use the Help menu for tutorial. Thus, I do NOT think it is a 
good idea to display this splash-screen when given a <filename>.


  2- elisp files compression:
      . elisp source files are compressed on emacs 'make install'.
        Navigating through gzipped elisp source files is transparent.
        Byte-compiling gzipped elisp source files is not.

THIS HAPPENS ONLY FOR FILES WITH DEPENDENCIES.
THIS COULD BE AN ENHANCEMENT FOR THE NEXT RELEASE.
One could need to patch an emacs-provided elisp source file that has 
been gzipped and byte-compilation may fail if dependencies exist for 
this file.
Should it not be possible to have '--no_compress' (or look-alike) option 
to the 'configure' script so that problem for compilation transparency 
could be avoided?


  3- gdb
  3.1- gdb default behavior

      . GDB '--annotate=3' option is automatically added.
      . GDB finds the first executable in the current directory

THIS IS NOT A BUG but RATHER A SUGGESTION.
Default GDB behavior is to add the '--annotate=3' option that is unused 
by several GDB users. In our case, it has also made emacs freezing while 
typing a simple command such as 'help'.
Default GDB behavior is to find the first file matching 'execute' mode 
on in the current directory. The problem is that it also finds scripts 
(such as shell scripts) that are not 'debug-able'. I heard that emacs 
GDB had an enhancement to allow perl scripts debugging but it should not 
interfere with others. Perhaps an option/variable/... could help to 
disable this feature (e.g, variable gud-matching-executables-search).


  3.2- gdb navigation

      . GDB does not (always) navigate through source code.
        up/down/breakpoints/... do not switch to source code.

Here is a small/simple example:

-- main.c
  #include "pouet.h"
  int main () {
    pouet ();
  }

-- pouet.c
  #include "stdio.h"
  void pouet () {
    printf ("pouet-separate\n");
  }

-- pouet.h
  void pouet ();

--------------------

$ emacs
-> M-x gdb RET pouet RET
(gdb) b pouet
(gdb) r
(gdb) up
(gdb) do
(gdb)




Thanks a lot for your time and attention.

Regards,
Pierre-Louis ESCOUFLAIRE

____

This message and any files transmitted with it are legally privileged and 
intended for the sole use of the individual(s) or entity to whom they are 
addressed. If you are not the intended recipient, please notify the sender by 
reply and delete the message and any attachments from your system. Any 
unauthorised use or disclosure of the content of this message is strictly 
prohibited and may be unlawful.

Nothing in this e-mail message amounts to a contractual or legal commitment on 
the part of EUROCONTROL, unless it is confirmed by appropriately signed hard 
copy.

Any views expressed in this message are those of the sender.