Re: A suggestion about runtime files and documentation
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: I mean, that's not the point. The point is that the source code is using hardcoded directories, and that is not a good practice, even if you force to have all runtime files under the same directory, because someone could change one of the many variables under src/Makefile and have the files installed in a place where the source code (which doesn't use those variables) won't be able to find them. OK, so we should remove the variables from Makefile, so that nobody is tempted to change them. Yes. Avoiding the risk, so to say. It's mostly OK to hardcode the directory names in the source code, since they can't be changed without causing lots of trouble. Well, in Vim's case, yes. Otherwise, hardcoding thing is, IMHO, not a very good practice. I've modified other's code a couple of times and hardcoded paths were a pain in the a*s. If you really want to do it differently you are on your own. It's good that this is difficult, so that people who are causing problems for users will have to work hard to do that. I don't see how getting rid of hardcoded directories in the source code is going to cause problems for users ;) In fact, hardcoded directories may cause problems: if you modify src/Makefile and don't reflect those changes in the source, for example. Of course, end users shouldn't modify things under src/Makefile if they're marked as DON'T MODIFY THIS, but they don't have to work hard to do that and it will cause problems. The warning is there: ### Location of Vim files (should not need to be changed, and ### some things might not work when they are changed!) My first though when I saw that warning was well, I'm supposed not to change this to fit files in my hierarchy, but the fact is that I can, and the Makefile is organized so changing these kind of variables move files around, like VIMRTLOC, so Given that you *must* change some of these variables in order to place runtime files in a non-default place, changing the rest is tempting if you need to move files around, and looking at the code to see which ones you can touch and which ones must remain intact is the hard job. Changing them is the non-hard job, and the errors that will appear not always are easy to connect to the modifications in the Makefile. If you don't want the hardcoded dirs removed (and that's your design, so I respect that), then how about getting rid of variables in the *SUBDIR and *SUBLOC families? This way is not hard, but IMPOSSIBLE to break things even using the hardcoded directories :) The change is amazingly simple and makes sense: SUBDIR variables are only used by SUBLOC variables, and those in turn are only used in the DEST_ variables, which make use of DESTDIR. A simple substitution will avoid risks and then users will *really* have to work harder to break things. And that includes annoying users like me ;))) I think this is a good idea (much less intrusive than that of modifying the source code) but hey, I'm not going to argue with you because I *really* love vim like it is now and I consider your work an amazing piece of code: elegant, easy to follow and does its job amazingly good. I'm not licking your arse ;), it's really what I think of vim. Consider the issue just a suggestion from a fan ;) Mostly this can be done. Cleans it up quite a bit. Only reason I can think of to keep the variables is to avoid confusion about using the name for something else than the subdirectory name. If you want me to, I can prepare a patch (agains 7.0.188) for the Makefile, and you can see if you like it. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: A suggestion about runtime files and documentation
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: Bram Moolenaar wrote: [...] I don't see how getting rid of hardcoded directories in the source code is going to cause problems for users ;) In fact, hardcoded directories may cause problems: if you modify src/Makefile and don't reflect those changes in the source, for example. Of course, end users shouldn't modify things under src/Makefile if they're marked as DON'T MODIFY THIS, but they don't have to work hard to do that and it will cause problems. The warning is there: ### Location of Vim files (should not need to be changed, and ### some things might not work when they are changed!) [...] Even though the README mentions it (recommends it?), personally I don't believe in modifying the Makefile. I don't do it, because I think the same. I just pass the variables to make, and I must confess that it is risky, because the Makefile can ignore or even replace command line arguments (Vim's makefile doesn't). I also believe in installing programs in their standard locations, even if installing elsewhere might cause no trouble: if a standard install doesn't work in the standard location, it's probably a bug; in a nonstandard location, it could quite well be a false maneuver. I would call it default locations and not standard locations. I think that a standard location is where the sysadmin feels a file belongs, following his system policies. And under UNIX, this can be a bit tricky, because some sysadmins will place some files in certain dirs so an app they have to perform some admin task will do its work easily, or things like that. Vim, being an editor with a big runtime, is a very special case, but on the average, any application using autoconf doesn't care about where its files are, as long as you have told it through configure at build time. Not a big deal using symlinks, of course (e.g., so the backup tool finds the files in the system's standard locations), but I prefer the autoconf way instead of having to tell things to make ;) I can live with all this, anyway ;) I'll try my best to prepare the patches but fortunately this is by no means urgent. Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: A suggestion about runtime files and documentation
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: Don't take me wrong: I'm not critisizing Bram's amazing work with Vim, and I'm not asking for this to be fixed. What I really mean is that Vim will be more flexible if it doesn't have that hardcoded paths and that I'm ready to prepare patches to modify this, one dir per patch, if Bram will accept them. So, Bram, if you could tell me where the limits are for the patches you will accept, or if you could tell me a good reason for not doing this (and I don't want this done is a perfectly good reason for me, Vim is yours and not mine, and it's good enough for me as it is), I will prepare as many patches as needed to fix this situation, at least for things like documentation, the runtime subdirs can be fixed after that. I recommend putting the files below the $VIMRUNTIME directory. Thus keep all Vim runtime files together. I don't see how this can break any recommendation. How can the LSB define something that goes against how Vim uses subdirectories in $VIMRUNTIME? This is not about policy, under LSB all vim files fit together under /usr/share/lib/vim, for example. That's not the point. In fact, even considering that help files are documentation (and you've stated clearly that they are not, in other message), a simple symlink will do the job for tools that handle documentation automatically. I mean, that's not the point. The point is that the source code is using hardcoded directories, and that is not a good practice, even if you force to have all runtime files under the same directory, because someone could change one of the many variables under src/Makefile and have the files installed in a place where the source code (which doesn't use those variables) won't be able to find them. If you really want to do it differently you are on your own. It's good that this is difficult, so that people who are causing problems for users will have to work hard to do that. I don't see how getting rid of hardcoded directories in the source code is going to cause problems for users ;) In fact, hardcoded directories may cause problems: if you modify src/Makefile and don't reflect those changes in the source, for example. Of course, end users shouldn't modify things under src/Makefile if they're marked as DON'T MODIFY THIS, but they don't have to work hard to do that and it will cause problems. If you don't want the hardcoded dirs removed (and that's your design, so I respect that), then how about getting rid of variables in the *SUBDIR and *SUBLOC families? This way is not hard, but IMPOSSIBLE to break things even using the hardcoded directories :) The change is amazingly simple and makes sense: SUBDIR variables are only used by SUBLOC variables, and those in turn are only used in the DEST_ variables, which make use of DESTDIR. A simple substitution will avoid risks and then users will *really* have to work harder to break things. And that includes annoying users like me ;))) I think this is a good idea (much less intrusive than that of modifying the source code) but hey, I'm not going to argue with you because I *really* love vim like it is now and I consider your work an amazing piece of code: elegant, easy to follow and does its job amazingly good. I'm not licking your arse ;), it's really what I think of vim. Consider the issue just a suggestion from a fan ;) Again, thanks for your answer and for taking the time :) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: A suggestion about runtime files and documentation
DervishD wrote: I mean, that's not the point. The point is that the source code is using hardcoded directories, and that is not a good practice, even if you force to have all runtime files under the same directory, because someone could change one of the many variables under src/Makefile and have the files installed in a place where the source code (which doesn't use those variables) won't be able to find them. OK, so we should remove the variables from Makefile, so that nobody is tempted to change them. It's mostly OK to hardcode the directory names in the source code, since they can't be changed without causing lots of trouble. Of course it would be nicer to put them together somewhere, but since C doesn't support string concatenation this causes inefficient string operations in quite a few places. E.g. to source the syntax/syncolor.vim script you would first need to use sprintf into a buffer. If you really want to do it differently you are on your own. It's good that this is difficult, so that people who are causing problems for users will have to work hard to do that. I don't see how getting rid of hardcoded directories in the source code is going to cause problems for users ;) In fact, hardcoded directories may cause problems: if you modify src/Makefile and don't reflect those changes in the source, for example. Of course, end users shouldn't modify things under src/Makefile if they're marked as DON'T MODIFY THIS, but they don't have to work hard to do that and it will cause problems. The warning is there: ### Location of Vim files (should not need to be changed, and ### some things might not work when they are changed!) If you don't want the hardcoded dirs removed (and that's your design, so I respect that), then how about getting rid of variables in the *SUBDIR and *SUBLOC families? This way is not hard, but IMPOSSIBLE to break things even using the hardcoded directories :) The change is amazingly simple and makes sense: SUBDIR variables are only used by SUBLOC variables, and those in turn are only used in the DEST_ variables, which make use of DESTDIR. A simple substitution will avoid risks and then users will *really* have to work harder to break things. And that includes annoying users like me ;))) I think this is a good idea (much less intrusive than that of modifying the source code) but hey, I'm not going to argue with you because I *really* love vim like it is now and I consider your work an amazing piece of code: elegant, easy to follow and does its job amazingly good. I'm not licking your arse ;), it's really what I think of vim. Consider the issue just a suggestion from a fan ;) Mostly this can be done. Cleans it up quite a bit. Only reason I can think of to keep the variables is to avoid confusion about using the name for something else than the subdirectory name. -- hundred-and-one symptoms of being an internet addict: 70. ISDN lines are added to your house on a hourly basis /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: A suggestion about runtime files and documentation
DervishD wrote: Hi all, specially Bram :) The source code for vim is full of hardcoded directories, rendering useless the constants defined in src/Makefile. Moreover, it doesn't use configure values to establish locations, but that's a minor problem. The major problem is that this scheme breaks LSB for example (which is not a big deal anyway), but the real problem is that the code has dirs hardcoded, and that's not a good idea, usually. Don't take me wrong: I'm not critisizing Bram's amazing work with Vim, and I'm not asking for this to be fixed. What I really mean is that Vim will be more flexible if it doesn't have that hardcoded paths and that I'm ready to prepare patches to modify this, one dir per patch, if Bram will accept them. So, Bram, if you could tell me where the limits are for the patches you will accept, or if you could tell me a good reason for not doing this (and I don't want this done is a perfectly good reason for me, Vim is yours and not mine, and it's good enough for me as it is), I will prepare as many patches as needed to fix this situation, at least for things like documentation, the runtime subdirs can be fixed after that. I recommend putting the files below the $VIMRUNTIME directory. Thus keep all Vim runtime files together. I don't see how this can break any recommendation. How can the LSB define something that goes against how Vim uses subdirectories in $VIMRUNTIME? If you really want to do it differently you are on your own. It's good that this is difficult, so that people who are causing problems for users will have to work hard to do that. -- Time is money. Especially if you make clocks. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
