$EDITOR to open at file end?

$EDITOR to open at file end?

[Bob Proulx]

With "the other editor" I can set editor to be "vi + file" and when
opening the file it will automatically jump to the end of the file.
With less there is "less +G file" and it will jump to the end of the
file.  (And also "less +/PATTERN" is useful too.)

    +[num]      For the first file the cursor will be positioned on line
                "num".   If "num" is missing, the cursor will be positioned
                on the last line.

For emacs however there is only:

       +number Go to the line specified  by number (do not insert a
               space between the "+" sign and the number).  This
               applies only to the next file specified.

I don't see a way to do this with emacs.  I am hoping I am simply
missing the obvious.  The best I can come up with is to use a very
large number larger than the number of lines.

  emacs +999999 file

That works but feels like a hack.  Is there another way to instruct
emacs explicitly to open the file and go to the bottom of the file?

Thanks,
Bob

Re: $EDITOR to open at file end?

[Alexis]

On 2015-03-05T18:29:28+1100, Bob Proulx <bob@proulx.com> said:

 BP> Is there another way to instruct emacs explicitly to open the 
 file BP> and go to the bottom of the file?

Here's another possible kludge:

    $ emacs -Q --eval "(add-hook 'find-file-hook (lambda () 
    (goto-char (point-max))))"

:-)


Alexis.

Re: $EDITOR to open at file end?

[Philipp Stephani]

Bob Proulx <bob@proulx.com> schrieb am Do., 5. März 2015 um 08:29 Uhr:

> With "the other editor" I can set editor to be "vi + file" and when
> opening the file it will automatically jump to the end of the file.
> With less there is "less +G file" and it will jump to the end of the
> file.  (And also "less +/PATTERN" is useful too.)
>
>     +[num]      For the first file the cursor will be positioned on line
>                 "num".   If "num" is missing, the cursor will be positioned
>                 on the last line.
>
> For emacs however there is only:
>
>        +number Go to the line specified  by number (do not insert a
>                space between the "+" sign and the number).  This
>                applies only to the next file specified.
>

It shouldn't be too hard to add the vi behavior to startup.el. That won't
solve your current problem, but it would at least obviate the need for
workarounds in the future.

Re: $EDITOR to open at file end?

[Emanuel Berg]

Alexis <flexibeast@gmail.com> writes:

>> Is there another way to instruct emacs explicitly
>> to open the file and go to the bottom of the file?
>
> Here's another possible kludge:
>
>    $ emacs -Q --eval "(add-hook 'find-file-hook
> (lambda () (goto-char (point-max))))"
>
> :-)

I think you can remove that smiley, because that is
exactly it (or one of many "exactly it" I should say),
only I got the impression that the OP wanted this for
opening a specific file, not every file, and besides
he is likely to want his initialization intact (i.e.,
not the -Q option which I suspected is a leftover from
testing the command).

So: 

    emacs FILE --eval "(goto-char (point-max))"

In situations like these it is common to say that it
is better to keep Emacs up all the time and open files
from, not with, Emacs. So, let me tell you that it is
better to keep Emacs up all the time and open files
from, not with, Emacs. :)

-- 
underground experts united

Re: $EDITOR to open at file end?

[Bob Proulx]

Emanuel Berg wrote:
> Alexis writes:
> >> Is there another way to instruct emacs explicitly
> >> to open the file and go to the bottom of the file?
> >
> > Here's another possible kludge:
> >
> >    $ emacs -Q --eval "(add-hook 'find-file-hook
> > (lambda () (goto-char (point-max))))"
> >
> > :-)

Thanks for the suggestion.  However that -Q is a little harsh.  And
rewriting find-file so that every use of it thereafter jumps to the
end of the file is double harsh.  It does answer the question very
literally however.  Perhaps I should have clarified that everything
else should remain normal. (chuckle) :-)

> I think you can remove that smiley, because that is
> exactly it (or one of many "exactly it" I should say),
> only I got the impression that the OP wanted this for
> opening a specific file, not every file,

To avoid being vague I wanted this for an EDITOR setting for use with
mutt when logging in over ssh to a remote server.  This works.  But
the 999999 just feels like hack.

In the .mutt/muttrc file:
  set editor="emacs +999999"

> and besides he is likely to want his initialization intact (i.e.,
> not the -Q option which I suspected is a leftover from testing the
> command).

Right.  Use of -Q is right out! :-)

> So: 
>     emacs FILE --eval "(goto-char (point-max))"

Something like that sort'a works.  It leads me to an acceptable
answer.  Obviously I was hoping to use a "string with options"
followed by the filename in a configuration.  This requires the
configuration both before and after FILE.  I can get there however by
using a helper script.  I will call it muttemacs and have it do
something similar to this (written in compact form):

  #!/bin/sh
  test $# -ne 1 && { echo "Error: too many arguments" 1>&2; exit 1 ;}
  file=$1
  exec emacs "$file" --eval "(goto-char (point-max))"

> In situations like these it is common to say that it
> is better to keep Emacs up all the time and open files
> from, not with, Emacs. So, let me tell you that it is
> better to keep Emacs up all the time and open files
> from, not with, Emacs. :)

I knew someone would suggest to use an emacs-server with emacsclient
and screen/tmux and other types of suggestions.  But I didn't know how
to head that off.  Yes I am very much aware of them.  I almost always
run emacs inside of a screen session already.  I know I can set up to
automatically switch screen windows to the running emacs server
window.  All old stuff.  But that has nothing to do with wanting this
setup.  Doing that just doesn't make sense in the way I need it to
work.  I hadn't mentioned mutt before for fear people would suggest
running gnus or emacs-vm instead.  But in the end we all like what we
like.  And as an fyi heads up to anyone that cares I am losing network
connectivity to my servers in the next two weeks.  Everything needs to
pick up and move elsewhere.  Which is why I am making these changes.
It is causing me to rework much of the way I do things.  I am trying
to keep ahead of things and to remain functional through the upcoming
disruption.

Bob

Re: $EDITOR to open at file end?

[Bob Proulx]

Bob Proulx wrote:
> Emanuel Berg wrote:
> > Alexis writes:
> > > Here's another possible kludge:
> > >...
> >     emacs FILE --eval "(goto-char (point-max))"

I didn't mean to have been rude.  Thank you both for the suggestions!

Bob

Re: $EDITOR to open at file end?

[Alexis]

On 2015-03-07T11:57:38+1100, Bob Proulx <bob@proulx.com> said:

 BP> Bob Proulx wrote:

 >> Emanuel Berg wrote: > Alexis writes: > > Here's another 
 >> possible kludge: > >...  > emacs FILE --eval "(goto-char 
 >> (point-max))"

 BP> I didn't mean to have been rude.  Thank you both for the BP> 
 suggestions!

Oh, well, i must apologise in turn, as i really should have 
written ';-)' instead of ':-)' at the end of my previous message, 
as my code was rather tongue-in-cheek - sorry for not 
communicating that better!

i was actually testing possibilities with -Q in order to not load 
up my own config, which takes ~25s to work through; leaving it in 
the command line i shared with you was an error on my part. And i 
usually run Emacs in daemon mode, which means i make use of 
emacsclient from the command line; but i didn't want to assume 
that was an option in your context ....

Glad that Emanuel was able to offer you a sensible suggestion!


Alexis.

Re: $EDITOR to open at file end?

[Robert Thorpe]

Bob Proulx <bob@proulx.com> writes:
> I knew someone would suggest to use an emacs-server with emacsclient
> and screen/tmux and other types of suggestions.  But I didn't know how
> to head that off.  Yes I am very much aware of them.  I almost always
> run emacs inside of a screen session already.  I know I can set up to
> automatically switch screen windows to the running emacs server
> window.  All old stuff.  But that has nothing to do with wanting this
> setup.  Doing that just doesn't make sense in the way I need it to
> work

It sounds like you're using several computers in some way.  If you
describe the setup that would be useful.  The people on this list may
know a way to deal with it using emacsclient.

BR,
Robert Thorpe

Re: $EDITOR to open at file end?

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>> So: emacs FILE --eval "(goto-char (point-max))"
>
> ... This requires the configuration both before and
> after FILE.

If that's a problem, I don't think the +99... hack was
bad.

Or:

    emacs +`perl -MPOSIX -le 'print INT_MAX'` FILE

which uses data in /usr/include/limits.h.

-- 
underground experts united

Re: $EDITOR to open at file end?

[Bob Proulx]

Emanuel Berg wrote:
> Bob Proulx writes:
> >> So: emacs FILE --eval "(goto-char (point-max))"
> > ... This requires the configuration both before and
> > after FILE.
> 
> If that's a problem, I don't think the +99... hack was
> bad.

Maybe not so bad.  I am unlikely to edit an email with more than
999999 lines.  And if I do then I can deal with it on the fly.  It is
just a LARGENUMBER.

>     emacs +`perl -MPOSIX -le 'print INT_MAX'` FILE
> which uses data in /usr/include/limits.h.

That just swaps 999999 for a larger value of LARGENUMBER.  I don't
think it intrinsically changes the flavor of the issue.

Upon reflection I think the +999999 wasn't so bad.  Although I like
the exactness of the solution for (goto-char (point-max)).  Having
implemented that already using a helper script I probably won't walk
away from it.

Thanks,
Bob

Re: $EDITOR to open at file end?

[Emanuel Berg]

Bob Proulx <bob@proulx.com> writes:

>> emacs +`perl -MPOSIX -le 'print INT_MAX'` FILE
>> which uses data in /usr/include/limits.h.
>
> That just swaps 999999 for a larger value of
> LARGENUMBER. I don't think it intrinsically changes
> the flavor of the issue.

In practice, it is worse because it requires an extra
processes to be launched as well as Perl to be
installed on a POSIX system. No, it is only
"poster politics" - it never feels good to hard code
anything. That's a good gut feeling to have acquired,
but one should be aware when the (most often) healthy
gut feeling crosses the line and gets irrational. On
the third hand, if it bugs you enough, who cares if it
is irrational as long as it works and is interesting
to do. Then what is rational about it is that it works
and is interesting to do and doesn't bug you.

For example, how does this look:

    (setq last-char-english-alphabet "z")
    (setq english-alphabet-number-of-chars 26)

compared to this?

    (setq english-alphabet '("a" "b" "..." "z"))
    (setq english-alphabet-number-of-chars (length english-alphabet))
    (setq last-char-english-alphabet (car (last english-alphabet)))

> Upon reflection I think the +999999 wasn't so bad.
> Although I like the exactness of the solution for
> (goto-char (point-max)). Having implemented that
> already using a helper script I probably won't walk
> away from it.

If the options on both sides of FILE isn't a problem
that is the best solution I can think of.

-- 
underground experts united

Re: $EDITOR to open at file end?

[Bob Proulx]

Robert Thorpe wrote:
> It sounds like you're using several computers in some way.  If you
> describe the setup that would be useful.

I have already described this.  And I have already gotten good answers
and good discussion.  I consider the original problem solved.

I am very familiar with emacsclient and already use it all of the
time.  I think the 'emacsclient -t' feature is a killer feature of
emacs.

Among the different ways I read and respond to email is that I will
ssh into my desktop from somewhere else on the network.  Most of the
time that is using OpenSSH from a real system.  Sometimes that means
using putty.exe.  Sometimes that means using a tablet.

In the terminal I will run screen.  When working over a long WAN link
from an unreliable network location using screen is a great saver
after a dropped connection.  Screen with emacs is an awesome
combination after the default screen escape character of C-a has been
changed to C-z.  C-a is inconvenient for me as either an emacs or vi
user.  I also use C-z for job control all of the time too.  But I
don't usually use job control in screen.  In screen I would normally
use different windows in those times when I would normally use C-z and
job control.  Therefore using C-z for the screen escape makes the most
sense for me.  I also like having a hard status bar.  And the extended
terminal attributes is useful too.  Here would be a minimum.

  escape ^z^z
  hardstatus on
  hardstatus alwayslastline
  hardstatus string "%{.bW}%-w%{.rW}%n %t%{-}%+w %=%{..G} %H %{..Y} %m/%d %C%a "

In a screen window I will run mutt.  I normally use mutt for all of my
email.  I may have more than 10,000 messages various mailboxes such as
mailing lists.  Mutt will open them in less than a second.  It is very
fast.  I know many people at this point will want to suggest using
imap.  Using imap slows that down quite significantly!  For me imap
just isn't as good as having real mailboxes available.

When replying to a message in mutt I of course use emacs to edit my
message.  Mutt prepares a template and quotes the previous message for
the reply.  I write the reply in a newly started emacs running in a
terminal environment.

This thought of starting a new emacs will scare some people that have
long emacs initialization that takes a long time to start.  I have
optimized my emacs init so that it doesn't take very long to start.  I
wrote about this on this list a couple of years ago.

  $ time emacs -f kill-emacs
  real    0m0.155s
  user    0m0.128s
  sys     0m0.024s

Emacs can really be quite fast!  Even if I force dropping all of the
caches and requiring everything to load from the file system (SSD)
then things are quite fast.  The SSD makes a large difference over
spinning disks here.  My SSD cold start is around 1.5 seconds and my
spinning disk cold start time is around 6-7 seconds.  But I don't
usually do cold starts except for testing.  Typical for me has the
caches being warm and speed is as above.

> The people on this list may know a way to deal with it using
> emacsclient.

In the past I have used emacs, screen, and other applications in this
following configuration.  Some people may like this.  I have a helper
script that I call emacs-screen:

  #!/bin/sh
  screen -X select 0
  emacsclient "$@"
  screen -X select $WINDOW

In screen $WINDOW is the window number.  "0" for the first window.
"1" for the next and so forth.  The above assumes emacs running in the
first window 0 and that emacs has server-start running an emacs
server.  Executing "screen -X select 0" tells screen to make window 0
the currently visible window.  Running emacsclient of course tells
emacs to visit that file.  After editing that file C-x # runs
server-edit causing emacsclient to exit.  "screen -X select $WINDOW"
tells screen to make the previous window, the one you started in,
visible again effectively returning you back to mutt.

This type of environment allows you to use an emacs server to edit
email with mutt and avoid the startup time.  Plus all of your
previously exiting visited buffers are still availble allowing an easy
cut and paste of text all around.  It is a good setup.  I hope people
reading this give it a try.  It's pretty cool!

I don't normally use it however.  As you can see the startup time
isn't a problem for me.  My emacs starts quite fast.  I don't miss
connecting to an always running emacs with all of the visited buffers
already there.  Actually I rather like the pristine cleanness of a
freshly started emacs.  Everything is clean and nice right at that
point.  I also don't like the need to have the exact environment up
and running in order to operate.  Not much hardship.  Here is the
setup for the above.  This starts up screen, runs emacs as the first
process in window 0, tells emacs to start a server.

  $ screen emacs -f server-start

This doesn't even talk about the killer feature "emacsclient -t".
When I am doing software development on a system and it is convenient
that it be *over there on that system* then I do all of the above of
starting an emacs with a server running.  Then I connect to it using
"emacsclient -t" outside of screen.  That attaches my terminal to the
currently running emacs.  I have a persistently running emacs client
with all of my state available to me for that development.  Using
screen is awesome if I want everything in one terminal.  But if I have
my large dual monitor desktop with lots of space then I will usually
run multiple terminals outside of screen.  It all depends upon what I
am wanting to do at the time.

Emacs 24 has some annoying mode line font features that become visible
when using "term screen-256color".  I would speak about them but I
have written much here already so will stop at this point.

Previously I used emacs-vm to read email.  Previous to using emacs-vm
I used rmail.  I don't want to offend anyone that is currently using
rmail but I found emacs-vm to be vastly superior.  I liked emacs-vm.
I used it for a long time.  But I like using mutt better.

Long, long ago I had tried gnus.  This was a long time ago and it was
glacially slow then.  I know that things have changed considerably and
trying gnus again is on my todo list one of these days.  I will
eventually get around to it.  Learning curve being that it is one must
learn to pace themselves! :-)

Bob

Re: $EDITOR to open at file end?

[Robert Thorpe]

Bob Proulx <bob@proulx.com> writes:

> Robert Thorpe wrote:
>> It sounds like you're using several computers in some way.  If you
>> describe the setup that would be useful.
...
>   $ time emacs -f kill-emacs
>   real    0m0.155s
>   user    0m0.128s
>   sys     0m0.024s
>
> Emacs can really be quite fast!

Fair enough.  I also use a minimalist init file that loads quickly.  My
Emacs doesn't start that quickly though, but that's probably because I
don't have an SSD.  Anyway, if you've got that tuned you don't need to
worry about emacs vs emacsclient.  Lots of people who use Emacs,
especially new users, seem to have huge init files, I was assuming you
were one of those.

BR,
Robert Thorpe

Re: $EDITOR to open at file end?

[Bob Proulx]

Robert Thorpe wrote:
> Bob Proulx writes:
> >   $ time emacs -f kill-emacs
> >   real    0m0.155s
> >   user    0m0.128s
> >   sys     0m0.024s
> >
> > Emacs can really be quite fast!
> 
> Fair enough.  I also use a minimalist init file that loads quickly.  My
> Emacs doesn't start that quickly though, but that's probably because I
> don't have an SSD.

That is the warm cache performance and is independent of whether it is
an SSD or spinning media.  SSDs only help for the cold cache
performance.  My cold cache load on an SSD is about 1.5 seconds.  My
cold cache load on spinning media is around 6-7 seconds.

> Anyway, if you've got that tuned you don't need to worry about emacs
> vs emacsclient.  Lots of people who use Emacs, especially new users,
> seem to have huge init files, I was assuming you were one of those.

I would expect newcomers to have small init files.  It is us old
timers that have collected up much lint in them over the years.  I
have been using Emacs since version 18.

Bob

Re: $EDITOR to open at file end?

[Alexis]

On 2015-03-09T16:14:20+1100, Bob Proulx <bob@proulx.com> said:

BP> I would expect newcomers to have small init files.

Well, a number of newcomers nowadays are starting out by using 
prebuilt configs of some description, e.g.

https://github.com/bbatsov/prelude

or

https://github.com/syl20bnr/spacemacs

which those newcomers feel helps them getting started with 
Emacs. i've seen several arguments both for and against such 
things; personally, i think it's great that members of the Emacs 
community are trying to help ease some newcomers' transition to 
Emacs. Some people work best by starting out in a relatively 
familiar environment from which they can gradually move away, 
rather than having to learn a whole lot of new behaviours 
simultaneously.

 BP> It is us old BP> timers that have collected up much lint in 
 them over the years.  BP> I have been using Emacs since version 
 18.

:-) i think i first started using Emacs around some version 20 
release, though it's only in the last several years that i've been 
making increasingly heavy use of it. Still, yes, a lot of cruft 
built up until i started using org-babel to organise my config; 
that, together with being able to use package.el to manage the 
installation and update of almost all of the many extensions i 
use, has meant that there are increasingly fewer bits of cruft for 
me to manage. :-)


Alexis.