>> Alastair Rankine <arsptr(a)internode.on.net> seems to
On 23/02/2009, at 7:15 AM, DaveS wrote:
> Obviously the number one priority is ensuring that parsing works
> on all platforms. Could we do a bit of inspection and do a best
> based on the user's platform. Barring that, how about exposing this
> so a
> knowledgeable user can specify a value if they choose.
Another idea occurred to me. The mode of the new file is almost
certainly going to match that of the parsed parent file. In other
words, if we are parsing a c++ file, then all of the #included files
can be parsed as c++ as well. Hence as a fallback, if after loading
the file with find-file-noselect we find that there is no mode set, we
can attempt to parse it using whatever the parent (not sure if that's
the right terminology here) file's mode is.
[ ... ]
I've contemplated this. I use this technique for the ctags parsing,
since the actual file isn't loaded. I also use it when I create
database objects tied to a file without ever loading the file in.
I've been hesitant to make these assumptions because there might not
be a starting file to derive a major-mode from. For example, if
someone wanted to pre-parse /usr/include/c++ then there is no starting
buffer to derive a mode from.
On the flip side, such an assumption would be handy for cases where a
.cpp file includes a .h file full of "#ifdef cplusplus" blocks that
you want parsed in C++ mode, not C mode. This is, as far as I can
tell, a problem unique to C/C++. It also exposes issues I have where
I try to parse .h files once, but the preprocessor symbols active can
change on a per-file basis.
As such, the best thing I can think to do is to allow Emacs to read a
file into a buffer, and choose the mode for me. I like it because I
don't have to do anything special. Or so I'd like to think anyway. :)
We just need to tune this special semantic-find-file-noselect to have
the best set of disabling settings.
Eric Ludlam: eric(a)siege-engine.com
XEmacs-Beta mailing list