»
« home   paste   Anonymous | Login | Signup for a new account 04-26-2017 13:48 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
0000073 [GeSHi] core feature N/A 05-09-06 07:38 05-27-06 23:45
Reporter BenBE View Status public  
Assigned To nigel
Priority low Resolution fixed  
Status closed   Product Version 1.1.1alpha4
Summary 0000073: Context Load Handler Spec by Context Adding Proc
Description Best described as in a mail to nigel said:

BenBE:
I noticed an issue about the use of common files: You still have to declare a handler for each context. Wouldn''t it be nicer for every contect that you could specify a "default" context loader proc.

nigel:
So, define a function like geshi_lang_common(), and if the geshi_lang_lang_context_name function doesn't exist, call the common function?

BenBE:
Not exactly... For single string, multicomment and such you always repeat to call the common inclusion procedures for most subcontexts. When doing this
relatively (like this will do for Delphi best IMHO) you would have to write an handler for each subcontext where those contexts are imported ...

Furthermore you often only have one single call inside such a handler which actually loads the data of the context.

Wouldn't it be much preferable if you had a parameter that you only give a name for a procedure that will init that context?

Thus:

$context-addChild('somecontext', '', 'geshi_lang_strings');

in any subcontext would look for $this->contextpath/$name (default init name) and if that function was not found but a default one given, load the data by
calling the default handler and crash only if that parameter is not
present.

Where "default handler" is to be understood as a context init function (same params as ATM too) which gets called if the init function that normally would result out of that call could not be found.
Additional Information
Attached Files

- Relationships

- Notes
(0000358)
nigel
05-14-06 21:34

I made the changes necessary to mark this bug as fixed (and converted delphi and php to use it).

However, I noticed that all I ended up doing was specifying the context name again for the third parameter. e.g., in delphi:

$context->addChild('delphi/delphi/single_comment', '', 'single_comment');

This would mean that geshi_delphi_single_comment was called. But in reality, we already have enough info to try to call this function, because we have the context name.

Perhaps I could add a check: if function_exists (geshi_lang_context_name), then call that. That would go between the default call (geshi_lang_lang_context_name) and the "custom" function name (geshi_lang_whatever_specified).
 
(0000360)
BenBE
05-14-06 21:54

k, I'll test it out ASAP ...

Regarding the respec of the context name: There might be rare cases where this isn't the case and while there isn't much performance loss caused by this there should be no real matter about this, shouldn't it?
 
(0000362)
nigel
05-14-06 22:19

I don't mean _replace_ this functionality by automatically looking at the context name, I mean use this as well. So you could specify a specific function name if you really wanted, but there'd be the check of geshi_lang_lang_context_name and geshi_lang_context_name first.
 
(0000364)
BenBE
05-14-06 23:37

OIC, k.
 
(0000372)
nigel
05-16-06 21:11

I fixed this up now - geshi_lang_context_name is looked for as well. I removed the extra stuff from the language files for delphi and PHP. Now there is only one case where the third parameter is needed - for single strings in delphi's preprocessor context, where 'single_string' is used to call geshi_delphi_single_string instead of it calling geshi_delphi_delphi_preprocessor_single_string and geshi_delphi_preprocessor_single_string.

I'm thinking now: perhaps if an init function is specified, it should be the *first* thing checked for, instead of the last? If the user specifies it they probably want it to override GeSHi's behaviour - maybe they have one of the default functions but want to call something else regardless. What do you think?
 
(0000378)
BenBE
05-16-06 23:08

Yes. that was my intension on this too. If the 3rd param is spec override the default behaviour and check for that function first.
 
(0000381)
nigel
05-17-06 09:40

OK, I'll do that later tonight.
 
(0000388)
nigel
05-17-06 20:10

Fix in cvs. Note that I changed the order, functions are tried in this order:

  * User-defined function (it's prefixed with geshi_lang_ to prevent naming conflicts)
  * geshi_lang_dialect_context_name
  * geshi_dialect_context_name
  * geshi_lang_context_name

The third and fourth ones are a disambiguation of the fallback function - if in the "main" language file, geshi_lang_context_name was called, which was correct, but in a dialect file geshi_dialect_context_name was called, which isn't what was expected in the case of PHP4/5.
 

- Issue History
Date Modified Username Field Change
05-09-06 07:38 BenBE New Issue
05-09-06 07:38 BenBE Status new => assigned
05-09-06 07:38 BenBE Assigned To  => nigel
05-14-06 21:34 nigel Note Added: 0000358
05-14-06 21:34 nigel Status assigned => feedback
05-14-06 21:54 BenBE Note Added: 0000360
05-14-06 22:19 nigel Note Added: 0000362
05-14-06 23:37 BenBE Note Added: 0000364
05-16-06 21:11 nigel Note Added: 0000372
05-16-06 23:08 BenBE Note Added: 0000378
05-17-06 09:40 nigel Note Added: 0000381
05-17-06 20:10 nigel Note Added: 0000388
05-17-06 20:10 nigel Status feedback => resolved
05-17-06 20:10 nigel Resolution open => fixed
05-17-06 20:10 nigel Fixed in Version  => 1.1.1alpha5
05-27-06 23:45 nigel Status resolved => closed

  


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