« home   paste   Anonymous | Login | Signup for a new account 04-26-2017 13:55 CEST
* X »
GeSHi - Generic Syntax Highlighter Syntax Coloriser for PHP

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000002 [GeSHi] core feature always 10-20-05 20:28 05-27-06 23:38
Reporter nigel View Status public  
Assigned To nigel
Priority normal Resolution fixed  
Status closed   Product Version 1.1.0alpha5
Summary 0000002: Should be possible to tweak context data dynamically
Description To prevent code duplication, OCCs should be able to modify the data they get from the base context.

This may already be easily possible, but I should think of the "right" way to do this also.
Additional Information The core issue here is that load() is called after the constructor, so we can't do:

$context =& new GeSHiContext(...);
$context->_contextDelimiters = array(...);

Because then load is called and your data is erased.

What could be good is if there were some methods:



That saved the changes. Then when load is called, they will get overwritten, but then they can be restored.

Ben suggests not too many methods, which is a fair point.

If this was done correctly, then the statements in context files could change from setting private member variables to $this-> method calls, which would be good from an encapsulation point of view.

In a related point, if a context is loaded and modified, then in theory you could load a context with keywords you want this way. But this is a poor way to get keywords you need, so a better way needs to be thought of.
Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

related to 0000006assigned BenBE Delphi support 
related to 0000013closed BenBE Keyword copying and context cloning can be put to good use for delphi 
related to 0000018assigned nigel Support for configurable language features 
related to 0000053assigned nigel Top-Level context for PHP only highlighting 
child of 0000032closed BenBE Copy stdprocs context for delphi/delphi/asm 

- Notes
10-21-05 22:27

This feature should provide possibilities to perform the following operations as stated in 0000013:

- Copy \ Clon (Symbolic and Hardlinking of operations)
- Add \ Alter \ Delete (Starter \ Ender \ Keyword \ KWGroup \ Symbols
- Modify Aliasing \ Subcontext relationships \ Inlining style

Symbolic means a simple copy of the current state; hardlinking means referencing the current data thus that changes performed on the original will appear on the copy too.

The modifications on the third line should be already available for static; extending them for dynamic use could raise power of context dynamics, but IMHO this is low priority as there are rare cases there could be a use of...
10-22-05 00:16

Hmm, I'll need more info about what you mean for that.

This is all still planning so feel free to post as much wild thoughts as you like ;). Nothing has been planned yet.

I'll need information regarding how you'd use this stuff in a context file. Use the delphi files for examples since they will use it anyway.
10-22-05 07:04

k, what do I mean by those lines:

- Copy \ Clon (Symbolic and Hardlinking of operations)

This operations mean that
Clon: all data is copied to the new context using the current settings.
e.g. I've the /delphi/exports context and tell clone to /delphi/external
exports and external would than contain the same data and references, except that context aliasing would be /delphi/external for the newly creates subcontext instead of the original /delphi/exports.

Copy: a subset of data of the current context is copied to an existing subcontext. This might be used to get the /delphi/keytypes into any other context that requires them (e.g. /delphi/property). Copying would require the information if it should justlink (reference) the current data (changes are reflected in both contexts) or create a duplicated subcontext containing the same data, that is independent of the source context.

- Add \ Alter \ Delete (Starter \ Ender \ Keyword \ KWGroup \ Symbols)

Well, those operations are just clear to understand how they are meant ;-)
Deletion could e.g. be used in that way that I request a independent copy of /delphi/exports as /delphi/external and remove any subpart (e.g. the parameter support) that is not needed for that new context.

Same applies for the other operations ...

- Modify Aliasing \ Subcontext relationships \ Inlining style

Well, this operations are a bit harder to understand what they could be used for. An example of use would be a cloned or copied context, that in opposite of its source WILL NOT inline or alias itself as anything else. An use inside the delphi language for this special operations isn't yet known to me, but I think they should be support for sake of completeness ...

One thing to take into account at this point is the fact, that due to context cloning it must be possible for ANY context, performing operations on (nearly*) ANY other context of that language. Nearly here means, that at least changes to cloned\copied contexts MUST be granted as you else could produce simple duplicates only.

Just ask if there are some thoughts missing ;-)
10-22-05 12:37

Okay, I understand the copy/clone one. I think this is a simple rename job in the case of one and a read of a different config file for the other.

And the second one I understand, that's the one I was thinking of that would be used most often.

I'm not quite sure about the last ones though. I'll try an example: For modifying aliasing, I presume you mean that I could clone the delphi/property context, except that the clone would be called delphi/property instead of delphi/delphi like it is with aliasing.

Subcontext relationships - Do you mean deleting/adding/modifying child contexts of a context you are changing?

And I'm not sure about inlining styles, what do you mean for this?

Of course all operations should be possible on any context. In fact, I see no reason why a context cannot clone a context from a completely different language, or perhaps from the common contexts. Of course this would create a dependency so whoever was working on the language would have to talk with the other language maker about it.
10-22-05 21:27

Reminder sent to: BenBE

Hardly related to my problem on bug 0000013.
10-22-05 21:41

Well, for the last ones I'll go a a bit more into detail:

Let's assume you've just cloned delphi/delphi/property ==> delphi/delphi/propnew.
The new context will be (as the old one) be aliased to delphi/delphi. Let's furthermore assume this is not intended for the clone and you want it to appear as delphi/delphi/property_ext ... Thus you'd set up an aliasing request; well, just as you saw.

The subcontext relationships are as simple. As you know does the property context contain a subcontext delphi/delphi/property/index (or simular). If there was the situation a cloned context should not have this subcontext, should have it under a different name, or should even own a new one the source context didn't you'd ask for altering of the subcontext relationships \ dependencies. So it's quite simular to the second group of operations, except that whole contexts are handled.

The inlineing controls stuff simular to the things you mentioned in bug 0000001, i.e. if a cloned context may be self-contained or not as this might changed for a cloned context too.

All in all I structured the operations in three groups (as you might have noticed ;-)). The first one was for "context creation \ duplication, the second one for modifications inside those contexts and the third group focuses on context relationships (and handles whole contexts).

I hope I now got a bit clearer on my thoughts ;-)
10-23-05 18:44

[note to self: could somehow use a flag to prevent load() overwriting fields if we have modified them using these sorts of changes]

A bit clearer now. I'll be sure to ask more questions when I get onto this.

If you have any more thoughts of course just post them.
12-21-05 00:04

While working on theming support, I was thinking a little about this bug.

I thought that it might prove useful if, say for delphi (I'm thinking of keytypes specifically), there was a new file created for delphi. Its contents would be:

$this->keywordGroup('keyident', array(
    'keywords....', ...

Then, wherever keyidents are needed this file is simply included.

The method keywordGroup would handle addition of the group to the _contextKeywords array. It could also handle merges and perhaps deletes too.

And eventually, all context files would be specified by method calls like this one to set delimiters, keywords, symbols...

This would make things easier for language maintainers, who would be maintaining files with collections of method calls instead of private field members (see the link to theming support now?), and easier for me if I decide that a field has to change for some reason. This is good OO practice.

And of course, language file maintainers can simply make those other files that only contain one or two method calls and include them in the right places in context files to prevent duplication.

This would handle the copy/clone case nicely. Additional methods or usages of methods could handle adding, altering and deleting.
12-21-05 01:42

Yeah, that addition in this way should do fine. I known Phobeus at DGL uses a simular system even with the old GeSHi, i.e. he has separate files for it's own additional keywords.

Just modify the language files this way.
BTW: How much progress with theming support? \ When to expect it to be done?

12-21-05 09:35

I will look into doing this modification after the next alpha is out.

Theming support will probably be more stable between christmas and new years, I have time off then. It's still got a bit of work to do of course.
05-19-06 21:33

I would say that this is pretty much solved. There's a hell of a lot you can do with the new format that you couldn't before.

If there are specific things here that can't be done by the new format, somebody can file a bug for them.
05-20-06 00:08

As there is no current need for the additional deletion features I think this can closed.
05-27-06 23:38

Issue closed.

- Issue History
Date Modified Username Field Change
10-20-05 20:28 nigel New Issue
10-20-05 20:28 nigel Status new => assigned
10-20-05 20:28 nigel Assigned To  => nigel
10-20-05 20:29 nigel Projection none => minor fix
10-20-05 20:29 nigel Additional Information Updated
10-20-05 20:47 nigel Relationship added related to 0000006
10-21-05 12:28 nigel Relationship added related to 0000013
10-21-05 22:27 BenBE Note Added: 0000009
10-22-05 00:16 nigel Note Added: 0000012
10-22-05 07:04 BenBE Note Added: 0000015
10-22-05 12:37 nigel Note Added: 0000018
10-22-05 21:27 BenBE Issue Monitored: BenBE
10-22-05 21:27 BenBE Note Added: 0000021
10-22-05 21:41 BenBE Note Added: 0000022
10-23-05 18:44 nigel Note Added: 0000023
10-28-05 04:46 BenBE Relationship added related to 0000018
12-12-05 09:20 BenBE Relationship added child of 0000032
12-21-05 00:04 nigel Note Added: 0000158
12-21-05 01:42 BenBE Note Added: 0000159
12-21-05 09:35 nigel Note Added: 0000160
12-24-05 15:23 nigel Relationship added related to 0000053
05-19-06 18:50 BenBE Note Added: 0000400
05-19-06 21:33 nigel Note Added: 0000401
05-20-06 00:08 BenBE Note Added: 0000405
05-20-06 00:08 BenBE Status assigned => resolved
05-20-06 00:08 BenBE Resolution open => fixed
05-20-06 00:08 BenBE Fixed in Version  => 1.1.1alpha5
05-27-06 23:38 nigel Status resolved => closed
05-27-06 23:38 nigel Note Added: 0000408


Mantis 1.0.0rc2[^]
Copyright © 2000 - 2005 Mantis Group
76 total queries executed.
51 unique queries executed.
Powered by Mantis Bugtracker