Re: RE : Re: Files from gnulib

> When we removed support for a lot of old systems 3 years ago MSDOS was > on the list of systems to be removed, nobody claimed to still use > Emacs on that platform. > Since then, there was a single user that said that he still used it. MS-DOS nowadays is a pretty special niche, so I'm not surpri

Re: Files from gnulib

> Here's a compromise that at least I can live with; hope others can, too: > 1) For c++defs.h and the lib/*.in.h files: rely on the automatic > renaming by djtar. Files that reference those will be edited by > config.bat as part of configuring Emacs for the MS-DOS build. > 2) For the 3

Re: Files from gnulib

> Based on the experience from GDB, here are the problems with this > approach: > . The remapping of file names cannot be fully automated. Once all > limits on file names are removed ("we don't want even the > slightest impediment", says Jim), sooner or later you get to the > point

Re: Files from gnulib

>> djtar -n emacs-25.chg emacs-25.tgz >> ... >> It is a bit more complex and error-prone for MS-DOS, yes. But >> it has the advantage of compartmentalizing the MS-DOS restrictions >> into the MS-DOS build instructions > Sorry, but these complications are unacceptable for me. We use > something l

Re: Files from gnulib

> For example, most files of CEDET were renamed to 8+3 some time ago, > breaking other elisp packages (e.g. company-mode, ecb, jde, matlab, > speechd-el) depending on them. Indeed the CEDET renaming was (and still is) a source of problems because there is still an "upstream" that hasn't done the s

Re: Files from gnulib

> The Emacs trunk already has seventeen other files > with 2 dots in their file names, with names like > lisp/gnus/.dir-locals.el I don't know how MSDOS handles names that start with dot, so either this is a special case that's OK, or it's indeed a problem which we hadn't noticed yet. > and admin

Re: Still unable to build trunk

>> It sounds harsh to me to ask every one who builds out of VCS to have >> to climb such a steep curve. > I dunno, I just started doing some Emacs development after > about five years' absence, and it was a pretty steep learning > curve for me. We decided a long time ago that it should be possible

Re: syncing Emacs from sources maintained elsewhere

> No further comment to my suggestion to sync some gnulib files to Emacs > , > so I installed that as revision 102878 on the Emacs trunk. I also regenerated > the source files by invoking "make sync-from-gnulib", and installed >

Re: [gnu-prog-discuss] url's in --help output

>>> + printf (_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT); [...] > However, as far as I know there isn't a gnulib translation domain that > is automatically used for messages in gnulib code when you import it to > a project. So the strings above will end up in every project's *.po > files,