Initial insertion point is wrong

[purcell]

If I make a second commit in a repo, the initial insertion point in the buffer is not at the beginning of the buffer: the point is usually in the middle of the commit boilerplate comment.

I guess that the COMMIT_EDITMSG file is being kept open between edits, and that the point is somehow being restored after the commit skeleton is inserted...

[tarsius]

Do you by any change have saveplace or something similar enabled globally or using text-mode-hook?

[purcell]

Hmmm, yes, I think I do... pointback...

[tarsius]

Function git-commit-mode contains a hack to prevent saveplace from having an effect. Maybe the same is necessary and can be done for pointback. After reading about pointback I want to use that too now, so there is hope I will find a way :-)

[purcell]

:-)

[tarsius]

Uh uh, it's one of these packages... How many Melpa packages are build from the Emacsmirror? Do you give the authors a nudge into the right direction when you have to do that? I used to do it, but am currently to busy to continue doing so, except when I use a package myself.

[purcell]

Not too many:

crontab-mode
csv-mode
dedicated
diminish
edit-list
escreen
fm
fold-dwim
hl-sexp
keydef
log4j-mode
mwe-log-commands
osx-plist
pager
parenface
pointback
psvn
revive
session
shimbun
smarty-mode
sml-mode
ssh-config-mode
textile-mode
xterm-frobs

And yes, we tend to follow up with authors where possible, but there's rarely much response.

[tarsius]

• No longer updated on the mirror: crontab-mode, dedicated, keydef, log4j-mode, pager, session, smarty-mode,
• Mirrored from github: https://github.com/jhgorrell/ssh-config-mode-el
• In GNU Elpa: csv-mode, sml-mode
• Removed from the mirror: shimbun
• All other (I think) are imported from files

[tarsius]

But lets take this to the Melpa issue tracker. I will open a new issue.

[praet]

On Sun, 15 Sep 2013 08:50:23 -0700, Jonas Bernoulli notifications@github.com wrote:

Function git-commit-mode contains a hack to prevent saveplace from
having an effect. Maybe the same is necessary and can be done for
pointback. After reading about pointback I want to use that to
now, so there is hope I will find a way :-)

No need to clutter git-commit-mode with hacks.

Adding something like this to your .emacs should work:

(add-hook 'find-file-hook
          #'(lambda ()
              (when (derived-mode-p 'git-commit-mode)
                (pointback-mode -1))))

Haven't tested it though, so YMMV.

Peace

Pieter

[tarsius]

melpa/melpa#1036

[tarsius]

Once it is verified this works I will add an entry to the (Magit) FAQ.

[praet]

On Mon, 16 Sep 2013 10:48:23 -0700, Jonas Bernoulli notifications@github.com wrote:

Once it is verified this works I will add an entry to the (Magit) FAQ.

Do you really think we should be documenting the shortcomings of
external code? IMO, people need to take responsibility for the stuff
they install and how it interacts with the rest of their environment.

If this issue were to be fixed or documented, it should be in
pointback, not in git-commit-mode. A good starting point for a
potential fix would be save-place-ignore-files-regexp (introduced in
Emacs v24.0 : emacs-mirror/emacs@bb44428e).

Oh and BTW, pointback-mode adds pointback-store-point to
post-command-hook, meaning pointback-store-point (which does
association list lookups and manipulation) will run every time you so
much as press a key! That's absolutely insane. We may have stumbled
upon the true cause of global warming here. ;)

Peace

Pieter

[tarsius]

Do you really think we should be documenting the shortcomings of external code?

If doing so is only little work, yes. In this case I would just point to this issue. That wouldn't make as the only package that informs about problems with (/in) other packages.

IMO, people need to take responsibility for the stuff they install and how it interacts with the rest of their environment.

The problem is that pointback isn't maintained *1. To deal with such packages I have created https://github.com/emacsorphanage. I haven't found the time to put that to use yet but a first success is that @purcell joined :-) So he or I (I am not using it yet but am interested in the functionality it provides) might end up fixing it there (if we cannot get upstream to do something about it). Considering that and how much @purcell does generally for Emacs packages he doesn't even use, and the users of these packagaes, we can put in the little extra effort.

*1 scratch that. It is maintained but doesn't use github/git/a vc. It is actually fairly popular so it is likely that many Magit users blame this problem an the latter and more specifically the new commit workflow I will likely send patches upstream (once I find the time to integrate that into my own setup).

But I do realize that this isn't just about this one package and that you are concerned that we might set a precedence. Well, if we have a few examples in the FAQ we can tell users who came here for help to help others by summarizing the required steps. Might even be a good way to get more community involvement. Considering that I am putting other stuff on Steve's todo list elsewhere, I don't think it is appropriate to ask for this in this case.

You are right about not adding kludges to Magit to overcome problems in other packages or misconfiguration. We shouldn't do that, except for built-in and highly popular packages. So I am closing this and adding a little not to the FAQ.

Ps: All the code we have to deal the emacsclient effectively is such a kludge that is only necessary because of misconfiguration. I am not happy about it but since we didn't keep the old mode as a fallback we don't have another option.