Opening file on click not only on '#include'

[dej.mi.5]

When you click on a line which begins with a "#include" or "$include" followed by a string (e. g. "#include <a.txt>") , a track menu appears which offers you to "Open <a.txt>". However, it works only with these two keywords.
My enhancement suggestion is to add a special keyword (e. g. "@import") to the documented class syntax highlighting file, which would determine keyword(s) which would open file straightly in the same manner is "#include" or "$include".

[skaemper]

Hi,
that sounds like a good idea, but then other words should be considered too: 'load' and 'require' for example - and I'm sure there are other situations where still other words are used. 'Use' for example, 'take', 'fetch', may be even 'grab'...

So my enhancement suggestion to the enhancement suggestion is to add this functionality to the document class settings. The information needed seems to be:

1. The key word to identify a file to be included
2. The character(s) used to delimit the file name ( <>,(),[],{} pairs, 's, "s, or a regular expression)

dej.mi.5, I suggest that you create a five-way-poll, so that we can vote and Jeffey's porgam can rank it.

Cheers

Stephan

[ben_josephs]

The key word to identify a file to be included

A key word isn't powerful enough. In C/C++ an included file is identified as \1 in something like one of these two regular expressions:

^[ \t]*#[ \t]*include[ \t]*"([^"]+)"
^[ \t]*#[ \t]*include[ \t]*<([^>]+)>

TextPad already handles the optional white space properly.

[skaemper]

Sorry that line was a bit misguiding.
I meant to say that there should be the possibility to set a special key word in the highlighting file (favourite_language.syn ) which denotes the fact that there's a file to be included, required, loaded or whatever (thus the configurability of theword )
Furthermore there should be a way to configure how the file should be separated (by pairs of parentheseses, braces, brackets, single or double quotes, or even white space or whatever...).

Hope I didn't mess up things even more with this posting

Cheers

Stephan

[ben_josephs]

there should be the possibility to set a special key word in the highlighting file

The identifier include is not a keyword in C or C++, and it cannot, on its own, be used to identify a reference to another file. There is no confusion in the following:

Code: Select all

#   include <stdio.h>

int include ;

And #include isn't a keyword either. It's two tokens that can be separated by arbitrary amounts of horizontal white space.

So something more than a keyword is required.

Hope I didn't mess up things even more with this posting

No. You just provided an opportunity for some more clarification :-)

[dej.mi.5]

Hi,

back to the original problem / suggestion:

The intent is to allow opening included file whose name is written in the text.

The question is how much exactly copy C/C++ syntax criterions.

If we want to simplify the intent, the problem definition can be formed as determining a keyword followed by another word (closed in brackets, 's etc. or not). If the keyword and the other word is found, an "Open ..." track menu item can appear.

If we don't require to fulfil all C/C++ syntax criterions - and possibly it won't be possible to fulfil all criterions of all languages - we could simplify in the manner described above.

Cheers

dej.mi.5

[skaemper]

there should be the possibility to set a special key word in the highlighting file

The identifier include is not a keyword in C or C++, and it cannot, on its own, be used to identify a reference to another file. There is no confusion in the following:

Code: Select all

#   include <stdio.h>

Hope I didn't mess up things even more with this posting

No. You just provided an opportunity for some more clarification

Good.
Now, I seem to have to set up some kind of generic terms to describe my idea. I'll do that without getting too formal.
Let's focus on programming languages where source files are read from text files (otherwise using TextPad wouldn't make too much sense after all ). Now, let's call the elements in these files tokens - no matter whether they are key words of that specific language, precompiler directives, methods of an object, functions, variable identifiers or what not.

In every language there are tokens which are used to refer to another source file. The 'typical' layout is:

Code: Select all

 file_refer_token whithespace pre_delimiter whithespace file_identifer whitespace post_delimiter whithespace

Some of the white space is usually optional, and in the more highlevel language there's not restriction of where to put the reference to the other file.
One problem I see are languages where the file_identifier may be any expression which yields a, say, string. That may be a variable name, a conditional expression or even an appropriate SQL query...
I wouldn't expect TextPad to solve that, because the editor just can't now it - I can't because it's only known at runtime.

BTW, most of the tokens in the C++ syntax definition file cpp.syn of TextPad aren't C++ key words, nevertheless they're placed in the sections [Keyword num] in the syntax file.

May idea is to have a key/value(s) pair in a syntax definition file to set a token, and another key/value pair to extract the file name form the whole contruction.

Code: Select all

ReferenceToken=include load, require
ReferendeDelimiter={},[],().<>,'',"",//

As I think of it, from this information TextPad should be able to generate an appropriate regular expression itself. 8)

Now, before this posting mutates into a complete essay, I'll just finish mentioning that I'm well awre of the fact that every answer raises even more questions...

Cheers
Stephan

PS: Loading 'system' files wouldn't be too easy that way anyway, since the system files/header (e.g. the STL stuff for C++) a usually not given whit a full path name, but the file name only. The languages themselves usually know where to look for those files, but you'd have to teach TextPad to do that somehow. That'll get really interesting the moment you use more than one compiler system...