Óscar Fuentes <[email protected]> writes:

> Rémi Vanicat <[email protected]> writes:
>
> [snip]
>
>> It would be much better if both function, and magit-log-infinite-length,
>> would be define globally.
>
> I was thinking about turning magit-log-infinite-length into a defcustom
> and give it a sensible default value instead a very big one. This would
> prevent Emacs running out of memory on very large Git projects.

Indeed.

>
> As for turning the lambdas into defuns, I fail to see the value of
> that. It allows the user to bind other keys to them, but then the text
> at the bottom of the log would be outdated (well, this could be fixed by
> discovering the current bindings, but I didn't care about that)

It's useful to add docstring for them. I know that docstring are missing
in a lot of command and function in magit, but we should try to not add
new function without docstring.

>
>> Remark that local-set-key do not do what you seem to believe it is doing:
>> it change the local-map. In the log buffer it is magit-mode-map, the map
>> used in status, log and commit buffer. 
>>
>> If you want to change it, change it in the centralized point.
>
> I know about the effect of local-set-key. This implementation is more a
> temporal hack while magit-log doesn't get its own major mode and
> menu. IMO, it is not elegant to pollute the magit-mode keymap definition
> with entries that shouldn't be there. The local-set-key solution will
> keep working once magit-mode is removed from the magit-log buffer.

I believe whoever do the splitting of mode should also split the key
map. 

At the opposite, the presence of local-set-key in non-standard place
will make more difficult to easily study what should be put where.


-- 
Rémi Vanicat


-- 
To unsubscribe, reply using "remove me" as the subject.

Reply via email to