[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New start up splash screen annoyance...

From: Eli Zaretskii
Subject: Re: New start up splash screen annoyance...
Date: Sun, 16 Sep 2007 01:10:49 +0300

> From: Mathias Megyei <address@hidden>
> Date: Sat, 15 Sep 2007 20:55:55 +0200
> Cc: address@hidden,address@hidden,address@hidden,address@hidden,address@hidden
> 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?

Well, if you build a lot on top of shell features, then it's clear why
you would prefer file arguments from the command line.

Me, I live inside Emacs and build almost everything on its features.
Starting Emacs without arguments is so hardwired into my brain that I
don't even think of any other possibility.

Which doesn't mean I like the current CVS behavior of displaying the
splash screen when a file argument was given.  I think I stated my
opinions on this well enough in this thread.

> When I come back to this Emacs and see the splash screen, then I
> have to think why did I start this Emacs?

As I said, I, too, don't like this behavior.

> 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

No.  For these use cases, I'd use emacsclient, and leave Emacs running
at all times.

But again, those are _my_ habits; YMMV.  We don't have to agree on

reply via email to

[Prev in Thread] Current Thread [Next in Thread]