Re: New start up splash screen annoyance...

[Mathias Megyei]

Hello Eli,

[I think you're doing a great job for Emacs and for the Emacs
 community. Thank you very much.
 Writing in english isn't easy for me. It takes time. Sometimes I
 don't find the right words and don't explain enough or clear.
 I would like to ask please don't assume I'm stupid or I don't
 use Emacs in an efficient way.]

Eli Zaretskii writes:
 > > From: Mathias Megyei <address@hidden>
 > > Date: Sat, 15 Sep 2007 12:17:23 +0200
 > > Cc: Juri Linkov <address@hidden>, address@hidden, address@hidden,
 > >    address@hidden
 > > 
 > >  > When I want to do this, I start Emacs and then visit the file.
 > >  > What's the advantage of specifying the file name as a command arg?
 > > 
 > >  It saves key strokes.

 It saves key strokes _and_ time (which is even more important).

 > You mean, the 1-key SPC vs the 3-key "C-x C-f"?  I think these savings
 > are too small to be significant.

 No. See above and below.

 > >  (Our log files at work are sometimes really big, loading them
 > >  one by one is much less convenient than typing
 > >  emacs FILE FILE2. Until emacs has finished loading them the user
 > >  can do something else.)
 > 
 > Don't those log files have something in common enough for specifying a
 > single wildcard argument to "C-x C-f"?

Sometimes. Often the file names are identical but are located in
completely different directories. (One file is in the workspace
of a different user or belongs to a related but different
project....)
When the user starts Emacs with file argument then he has already
some information about the file. Perhaps the file is already
available via shell features.
(Eg. perhaps he can use M-. (yank-last-arg) in Bash to get the
 path, which is much shorter than typing the
 absolute path after C-x C-f even using completion.)

There are many possiblities how pathnames are easy available
outside Emacs. Eg. by using Bash functions, Git user know about
'git ls-files', etc. Why shouldn't someone start Emacs with file
argument when he has the file more easily available in the shell?
(Of course we're using these tools in a *shell* buffer when we
have an Emacs already running in the right environment.)

 > > Another example: One experienced Emacs user at work often starts
 > > Emacs with 3 or more arguments when he's starting to work in a
 > > specific project evironment, because he knows, he will work on
 > > all that files the next hours.
 > 
 > The same can be accomplished by C-x C-f from inside a running Emacs.

Sigh. We're working on different projects. Each project has its
own environment. We have to start Emacs in the right project
environment in order to have write access to the project's data.
(In some cases we need to start Emacs in the right project
environment even for read access.)

We often use Bash functions to setup specific project environment
_and_ start Emacs. (Useful option for Emacs is to load the
project specific bookmark file.)
When I start the Bash function with name of the logfile that is
passed to Emacs, I can continue my previous work. When I come
back to this Emacs and see the splash screen, then I have to
think why did I start this Emacs?

We also use a batch-queuing system (SGE from Sun) to start
applications with specific needs on suitable hosts.
Sometimes we need to look at or even edit files with size of 300
or 400 MBs. This cannot be done on the local host with 1 GB
memory running 32 bit linux.
When the user submits his (interactive) job it takes several
seconds, a minute until the job gets started.

The workflow you're proposing would be in this case:
- submit Emacs job
- wait several seconds
- C-x C-f FILE
- wait longer

Our workflow is:
- submit Emacs with FILE as argument
- do something else
- come back to this Emacs if you have finished the other task

The "good habit" in Emacs' sense requires 2 user actions with
delay in between. It is less efficient than our usage.

Best Regards,

Mathias