Hi Bertrand, On Tue, Nov 30, 2010 at 12:42:44PM +0100, Bertrand Yvain wrote: > mutt should use PATH_MAX instead of _POSIX_PATH_MAX, this would allow to > push the boundary to the actuel limit of your system. yes, I also thought so! But of course that would lead to path-type variables of length 4096 on many systems, causing another imbalance with string-type variables. Is there a reason why mutt uses _POSIX_PATH_MAX (besides historical ones)? > As a work-around, I would suggest to set editor="vim -S lengthy/script" > instead of putting the script body on the commande line. The problem is that the vim-scripts are automatically generated and are each different. I patched mutt as a work-around (for me) :-). > > 1. Add a new variable type "command" > > This would make sense, since lots of variables are not really path names > > (although they usually contain one at the beginning), but commands that > > are handed over to system(3) and do not obey any maximum file path limit > > anyway. Currently, all those variables ($display_filter, $editor, ...) > > are expanded using mutt_expand_path(), which does not make much sense > > besides the tilde [~] for HOME (who uses $spoolfile at the beginning of > > $editor?), so this could lead to a cleaner handling. > > Indeed, a command is not a path. I would favor this configuration > variable type. However, I see no reason to omit path expansion. Of course path expansion could still be performed (maybe it is good for backwards-compatibility). But I can't imagine a realistic scenario where it would be useful :-) (maybe one editor per mailbox: editor="^/editor") Greetings, Johannes
Attachment:
pgpaKtvCh3QoJ.pgp
Description: PGP signature