Emerald Editor Discussion
September 25, 2017, 04:08:48 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: 1 2 [3] 4
  Print  
Author Topic: Syntax format  (Read 39119 times)
0 Members and 1 Guest are viewing this topic.
daemon
Developers
Gem Cutter
***
Posts: 107


WWW
« Reply #30 on: May 25, 2006, 04:06:33 am »

Code completion will definitely be an option if it is included (not sure it will make it into 1.0).
Logged
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #31 on: May 25, 2006, 06:27:10 pm »

I LOVE code completion, but if it's an add-in, should the code completion info be in separate syntax files from the highlighting files?  It seems like the code completion data will need to be very detailed in order to be very helpful and possibly too heavy to include in the main distribution.  (?)
Logged
dsvick
Beta Testers
Senior Miner
***
Posts: 52



WWW
« Reply #32 on: May 25, 2006, 07:14:16 pm »

Matthew brings up a good point.

If code complete is not part of the 'core' release and is an add-in or part of more feature filled release it might reduce the size of the distribution to have the code complete files separate. On the other hand though, if we did that then some keywords would appear in two places, once in the basic syntax files and once in the code complete files. Not knowing how we are going to implement either it is hard to say if that might be an issue or not.

Maybe it can be done in such a way that if code complete is enabled that function names in the base syntax file are ignored, or that the base syntax file is ignored and only the code complete file is used (but then the code complete file would need to include non function keywords also).

Unless someone has a decent understanding of how best to implement it, we might be better off waiting on a final decision on the file structure. Then we can see how much bigger it will make the distributions.
Logged

Dave
Zhrakkan
Official Mascot!
Beta Testers
Gem Cutter
***
Posts: 177



WWW
« Reply #33 on: May 25, 2006, 07:37:04 pm »

I think code completion, should be part of the syntax file, and of course, once imported into the app via a plug-in it can be disabled, since I may use the syntax, but not code-completion.
Logged

News Manager and Unofficial Mascot
Join the Emerald Editor Project - Message Me!
Emerald Editor - "A Jewel of an Editor"
-----by the way, that name is pronounced "Za-Rack-In"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #34 on: May 25, 2006, 08:59:45 pm »

Why do you think code completion should be part of the same file as the highlight?  Because of redundancy?  If so, I tend to agree with you.  However, it sounds like code completion is not important to everyone.  The questions seem to be whether the inclusion of code completion info will add significant bulk to the syntax files?

By the way, if the syntax file are done in xml, it would be easy to write a program to strip out the extra bulk of the code completion if desired.
Logged
SnakE
Miner
**
Posts: 13


« Reply #35 on: May 25, 2006, 09:29:26 pm »

I personally think that code completion based on hand-made config files is evil. Code completion engine must parse all the available sources for the given project and only complete names found in those sources. It also must be context-sensitive, not trying to complete to a name not visible in the current scope. Otherwise, I repeat, it's evil and will be disabled by a vast majority of users.

This is why only project-based IDEs feature decent code completion.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #36 on: May 26, 2006, 01:31:41 pm »

Well, if you have every word in a language already defined as part of your syntax, it shouldn't be too hard to add in autocomplete.

I like the comments, but please remember my original syntax was thrown together in about an hour, with limited practical knowledge of XML, and quite late at night for me!!

To answer a question earlier back, keyword prefix was put in so that the groups of functions (e.g. all the functions that begin with "image" or "image") can be grouped, so that instead of matching against a list of 3,000 separate distinct keywords, you're searching against a hundred individual prefixes, or against the non-grouped elements, e.g. you're looking for image first, then the rest of the word when searching. If you don't match against "image", you skip the rest of the elements under it, thus saving time.

I would hope that each syntax can be kept in a single file, whether that is just for highlighting, or autocomplete, because that simply makes it easier to install/maintain. That way there is only one file roaming around per "language" (e.g. PHP 4, PHP 5 are separate languages for the purpose of this debate)

It should be available for use, whether you use it or not, and since the code would be quite small (it's the data that's large) so we could provide the option in the code for it and let the user turn it off if they don't want the processing overhead (or they don't like it, and either may be as likely - I know I turn it off in OpenOffice.org, for example)


Looking at SnakE's suggestion of combining keywords, that works and is more compact. It did occur to me to implement it like that but I figured on the following arguments:
1. Auto complete/code completion cannot be defined in the same syntax.
2. Some languages make include keywords with spaces in them, which essentially screws up in that format.
3. I wanted to provide optional regular expression support for keywords, which would be difficult in that format.

That's what's behind my thinking, and I know it isn't the most compact, but I was writing fairly quickly, and from how I would write the parser for it (without having used any other XML parser, I'm going on how I would go about coding one) so that I minimised processing.

I don't have a problem with defining two files per syntax (kind of like how CE does it currently), although not for the same reasons. If we took that route, the first file would define the language syntax and keywords. Then we could use some shortened version of my syntax, or some hybrid of all the comments above - or something.

The second file would then contain all of the IDE-style autocomplete information, and would be totally optional.

Thoughts anyone?
Logged

"Cleverly disguised as a responsible adult!"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #37 on: May 26, 2006, 03:28:41 pm »

Quote from: Arantor
I don't have a problem with defining two files per syntax ... If we took that route, the first file would define the language syntax and keywords. ... The second file would then contain all of the IDE-style autocomplete information, and would be totally optional.
It seems like the syntax (language usage definition) *is* the autocomplete info.  You don't really need usage information for highlighting... only keywords.  (right?)

But why not include both in the same file and just make it easy to strip out the autocomplete if desired?  You could just put the keywords at the top and autocomplete at the bottom.  (if you want to avoid using two files)

For now, (until autocomplete is conquered--seems like that will be tricky) you could just have an empty tag at the bottom marking where it will eventually go... or... (weeping because I love autocomplete) just not include it at all right now.
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #38 on: May 26, 2006, 05:38:26 pm »

Hmmm. I think there is a little confusion between the terms of autocompletion and code completion - the two are not quite the same thing. I know I have probably been confusing the two myself, so let's tie this up here, as I don't want to cover old ground too much.

Autocomplete is where the editor picks up the rest of the word from the syntax - which it will already knows. Such a thing will (and necessarily should) be code-trivial to implement. I say "should" since it should be a case of matching a string against a partial string you already have. OpenOffice.org already does something like this, along with the so-called predictive text message authoring system on some mobile phones. It should be non-invasive, though, otherwise it becomes awkward.

It does also beg the question about case insensitive languages (e.g. PHP) where functions can be written either as (for example) imageColorAllocate or imagecolorallocate - personally I tend to write the latter, although the former is easier to read, and if I see code in the former style, I have to think a bit harder about understanding it (at least PHP, anyhow)

Code completion, however, is slightly different. This is where the editor suggests the syntax as well as completing the command, and is popular with IDEs. This will, obviously, require every function in a syntax has a function prototype and perhaps other information (maybe a description?). I wrote my syntax with this in mind, although of course in my XML suggestion it is optional and no harm, no foul if it isn't there.

To get an idea of size, I went and had a look at Bluefish (as suggested on other threads) and had a look at their PHP definitions file. All 1.2 MB of it, in fact - since PHP has over 3,000 functions, each with their own description and syntax and requirements. This is no little function guide.

Consequently, my thinking is that we can provide a syntax file which defines the language and functions (I keep wanting to use the word 'verbs' as that seems to be the best word for the job!), and which can be used for autocompletion purposes, and a second file for code completion.

I do take on board SnakE's comment, though, since it could potentially be very evil from some points of view, e.g. in Visual Basic using object.property - VB would be able to identify which properties were available to object, and bring them up, although it didn't always get it right. So even VB is not particular context sensitive sometimes. (I used to program VB in college, so I do have some programming experience with it)

With everything said here it does seem a bit much to have code completion built into the syntax file, although I know I originally suggested this for the purposes of installation etc. Having a second file does add a bit of space requirement, but not a huge amount. It would also mean that auto complete is available if code complete is not. It would also mean that we don't load the entire syntax unless the user specifies they want it - which means loading 50-100K of PHP syntax code, defined in XML or something, as opposed to 1.2MB of PHP syntax and function reference.
Logged

"Cleverly disguised as a responsible adult!"
Tom B
Prospector
*
Posts: 3


« Reply #39 on: June 08, 2006, 06:05:29 pm »

Hello, I stumbled across this site after looking for an updated version of crimson editor.

Code completion was mentioned here. It'd be nice to have IDE style code completion.

e.g. in php:
Code:
<?
class MyClass() {
function a() {}
function b() {}
}

$a = new MyClass();
?>
Typing $a-> (or even $a) should then bring up a menu containing b() and c().

Of course actual code completion based on existing functions would also be useful.

However, for this you would definatly need some sort of project system. CE's was quite nice but it'd be nice to point it to a folder and let the project be created from all the files/subfolders in it.

Anyway, I dont know a lot of C++ so I cant really comment on how hard this would be to implement.


Using XML as described earlier in this thread, imo, would make the syntax files unneccesarily large.  Using a CE style would make files a lot smaller e.g.

Code:
<database>
<function>mysql_connect</function>
<function>mysql_query</function>
</database>

Will use so much more space than

Code:
[Database]
mysql_connect
mysql_query


Code completion may be impossible in some cases.

Take perl for example.

Code:
use Win32::Clipboard;
my $CLIP = Win32::Clipboard();

When someone types $CLIP-> the only way to get the needed functions would be to load the module and parse parts of it..if it's even on the system. This is way beyond the scope of a text editor.
« Last Edit: June 08, 2006, 09:27:09 pm by Tom B » Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #40 on: June 08, 2006, 06:36:10 pm »

Very important points.

I think autocompletion of existing keywords is definitely possible, maybe even from the syntax files, but code completion, based on an IDE-style logic, pretty much has to be ruled out, because there is no way you can teach an editor about every kind of syntax file.

I think that pretty much wraps up the debate on which featureset to include as standard, and in theory there is no reason why it couldn't be implemented later as a plug-in.

For now I think we should look to defining the structure for the core syntaxes, without concentrating too much on IDE-style code completion. EE is not an IDE. It is a text editor. Admittedly a powerful one, but it is a text editor nonetheless. Perhaps even code completion (rather than autocompletion based on the keywords you give it as the core syntax) is simply too big a field.
Logged

"Cleverly disguised as a responsible adult!"
Matthew1344
Gem Cutter
****
Posts: 103


« Reply #41 on: June 08, 2006, 06:42:53 pm »

Hmmm... I can't disagree with you, but it's disappointing nonetheless.  I guess I subconsciously was hoping that EE would become a universal IDE.   Undecided

Still, isn't there still hope for those of us who love code completion?  Couldn't this be accomplished via an extension/plug-in/add-on ?
Logged
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #42 on: June 08, 2006, 08:39:01 pm »

I can see where you're coming from, but each language is so different (especially with the likes of Perl) that to write a universal IDE would be a mammoth task, since you have to teach it what are the core objects, and then you have the issues of objects that are coded in, and thus are available as you write them.

To describe all this in a single file would be a huge task (cf. Bluefish's 1.2MB PHP description file, and that says nothing of objects described by the edited text itself)

I suppose it is possible to build a plugin which does this, but I personally believe (and I hope I represent the majority of CE/EE users with this) that the nice that CE filled and EE will hopefully fill is not so much a full-blown IDE (there are other, more suitable, packages for that) more a specific editor.

This is not to say that EE will not sprout IDE-like features, but to teach EE to be a full IDE, especially if you have included objects (e.g. CPAN modules in Perl), you then have to essentially open them all to be able to describe what syntax you want to autocomplete.

That means if you reference 10 CPAN modules (which is not infeasible) you have to load all 10 CPAN modules to reference each of the syntaxes you need, which if nothing else is a massive drain on resources.
Logged

"Cleverly disguised as a responsible adult!"
awmyhr
Senior Miner
***
Posts: 95

Maintainer of Obscure and Unused Ports


WWW
« Reply #43 on: June 09, 2006, 11:29:25 pm »

One possible direction to take is to design EE in such a way that it itself can plug in to an already existing IDE.  Many IDE environments allow for the use of external editors - though I have no real experience in this area, so I may be speaking gibberish here.
Logged

-->>  This Space 4 Rent  <<--
Arantor
Site Administrator
Administrator
Master Jeweller
*****
Posts: 618



« Reply #44 on: June 10, 2006, 07:58:26 am »

I can see the logic there, but which IDE? The trouble is, each IDE is built ground-up to support the language and any bolt-ons that it wants to. (e.g. Visual Basic's IDE is designed specifically for Visual Basic etc.) That also means that the UI is built specifically to maintain it.

Consequently I think you'd end up having a separate plugin (possibly) for each UI, which I think would be too time consuming. Generally, people that use a specific language where there is an IDE do tend to use that IDE (*bracing myself for the flames*) I haven't yet met a Visual Basic programmer who'd rather use any other editor than the VB IDE.
Logged

"Cleverly disguised as a responsible adult!"
Pages: 1 2 [3] 4
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.089 seconds with 18 queries.