Hi,
I am using Geany to edit DocBook XML files, and I find the Symbols tab very useful, but I have the following questions about it:
- Currently the tab lists only the ID attributes of the <chapter> and <section> tags. How can I add other tags to this list? Especially <procedure>, but some others would be useful as well. - Is it possible to list the symbols by appearance by default? Currently I have to manually change this setting for every file. - The symbol tab now shows the sections and chapters in a separate list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
I am running Geany 1.22 (Tavira) on Ubuntu, built from source, so I can make minor changes to the code if needed.
Also, thank you very much for everyone involved for developing Geany, I really love it.
Regards,
Robert
On 10 April 2012 18:14, Robert Fekete fekete77.robert@gmail.com wrote:
Hi,
I am using Geany to edit DocBook XML files, and I find the Symbols tab very useful, but I have the following questions about it:
- Currently the tab lists only the ID attributes of the <chapter> and
<section> tags. How can I add other tags to this list? Especially <procedure>, but some others would be useful as well.
The tags are parsed by tagmanager/docbook.c
It is pretty small so you should not have too much trouble figuring out how to add extra element types if you can program in C.
- Is it possible to list the symbols by appearance by default?
Currently I have to manually change this setting for every file.
Well, for most programming, having the symbols in alphabetical order is the right thing to do, so thats the default. As you noted it is a per-file setting and there is no way to store it per file. Making the default per filetype might be your solution, but that would take some work and well, somebodys got to do it. But patches are welcome.
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes with suitable code changes in docbook.c to build the hierarchy in the right order, but practically no.
I am running Geany 1.22 (Tavira) on Ubuntu, built from source, so I can make minor changes to the code if needed.
I would say item 1 is minor and involves one file only, item 2 is somewhat more significant and may involve several files in Geany's core so more care is needed, and item 3 is forget it until the tagmanager is replaced (otherwise you may need to re-do it).
Cheers Lex
Hi Lex,
Thank you very much for your pointers and the swift reply. Though I am not a programmer, I managed to tweak docbook.c to extract the IDs from some other tags. (Probably not as it should, but works for me :) ) I'll see if I can convince someone with more skill to create a patch for #2, and send you a patch for it.
Kind Regards,
Robert
On Tue, Apr 10, 2012 at 10:57 AM, Lex Trotman elextr@gmail.com wrote:
On 10 April 2012 18:14, Robert Fekete fekete77.robert@gmail.com wrote:
Hi,
I am using Geany to edit DocBook XML files, and I find the Symbols tab very useful, but I have the following questions about it:
- Currently the tab lists only the ID attributes of the <chapter> and
<section> tags. How can I add other tags to this list? Especially <procedure>, but some others would be useful as well.
The tags are parsed by tagmanager/docbook.c
It is pretty small so you should not have too much trouble figuring out how to add extra element types if you can program in C.
- Is it possible to list the symbols by appearance by default?
Currently I have to manually change this setting for every file.
Well, for most programming, having the symbols in alphabetical order is the right thing to do, so thats the default. As you noted it is a per-file setting and there is no way to store it per file. Making the default per filetype might be your solution, but that would take some work and well, somebodys got to do it. But patches are welcome.
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes with suitable code changes in docbook.c to build the hierarchy in the right order, but practically no.
I am running Geany 1.22 (Tavira) on Ubuntu, built from source, so I can make minor changes to the code if needed.
I would say item 1 is minor and involves one file only, item 2 is somewhat more significant and may involve several files in Geany's core so more care is needed, and item 3 is forget it until the tagmanager is replaced (otherwise you may need to re-do it).
Cheers Lex _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 10/04/2012 09:57, Lex Trotman wrote:
On 10 April 2012 18:14, Robert Feketefekete77.robert@gmail.com wrote:
- Is it possible to list the symbols by appearance by default?
Currently I have to manually change this setting for every file.
Well, for most programming, having the symbols in alphabetical order is the right thing to do, so thats the default. As you noted it is a per-file setting and there is no way to store it per file. Making the default per filetype might be your solution, but that would take some work and well, somebodys got to do it. But patches are welcome.
Already implemented per-filetype - see symbol_list_sort_mode under: http://www.geany.org/manual/current/index.html#settings-section
It's the default for e.g. reStructuredText and could be for DocBook if that seems sensible.
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes
Is there? By who? Surely it would still need to parse tags with the CTags parsers even if it's managed differently than TagManager.
Also not sure what you mean by tagmanager not being good at hierarchies.
Regards, Nick
On 11 April 2012 02:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 10/04/2012 09:57, Lex Trotman wrote:
On 10 April 2012 18:14, Robert Feketefekete77.robert@gmail.com wrote:
- Is it possible to list the symbols by appearance by default?
Currently I have to manually change this setting for every file.
Well, for most programming, having the symbols in alphabetical order is the right thing to do, so thats the default. As you noted it is a per-file setting and there is no way to store it per file. Making the default per filetype might be your solution, but that would take some work and well, somebodys got to do it. But patches are welcome.
Already implemented per-filetype - see symbol_list_sort_mode under: http://www.geany.org/manual/current/index.html#settings-section
Thanks Nick, missed it.
It's the default for e.g. reStructuredText and could be for DocBook if that seems sensible.
Yes, Docbook users should decide, or Robert can just change his own Docbook filetype for now.
I notice that docbook isn't highlighted, should we make it use the Scintilla XML lexer? (since all the docbook I have is machine generated it has the extension xml any way so I had to set it to docbook)
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes
Is there? By who? Surely it would still need to parse tags with the CTags parsers even if it's managed differently than TagManager.
Columban is doing some work on it as he gets time and yes his current intention is to re-use the current parsers (at least when I asked a couple of weeks ago).
Also not sure what you mean by tagmanager not being good at hierarchies.
Well, to be explicit I guess its more to do with the problems with repeated names (although Colombans recent patch has greatly improved it). At the moment the docbook parser uses the id as the unique key and only shows entities with an id, but not all entities must have an ID. To show the entire hierarchy it would have repeated <chapter> and especially <section> <paragraph> etc it is going to need a better "uniquification" of the repeated name. Colomban uses line number to uniquify the key, but with XML you often get multiple things on a line so something else is needed, eg character number.
Cheers Lex
Regards, Nick
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 11/04/2012 01:50, Lex Trotman wrote:
I notice that docbook isn't highlighted, should we make it use the Scintilla XML lexer? (since all the docbook I have is machine generated it has the extension xml any way so I had to set it to docbook)
It was highlighted before, looks like it got broken in the highlightingmappings.h change. One problem is the filetype file uses [styling=XML], which is recursive so should be =HTML. Another is that the style strings in the header don't match. I've fixed these locally but I'm not yet sure if docbook styling needs to be separate.
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes
Is there? By who? Surely it would still need to parse tags with the CTags parsers even if it's managed differently than TagManager.
Columban is doing some work on it as he gets time and yes his current intention is to re-use the current parsers (at least when I asked a couple of weeks ago).
Also not sure what you mean by tagmanager not being good at hierarchies.
Well, to be explicit I guess its more to do with the problems with repeated names (although Colombans recent patch has greatly improved it). At the moment the docbook parser uses the id as the unique key and only shows entities with an id, but not all entities must have an ID. To show the entire hierarchy it would have repeated<chapter> and especially<section> <paragraph> etc it is going to need a better "uniquification" of the repeated name. Colomban uses line number to uniquify the key, but with XML you often get multiple things on a line so something else is needed, eg character number.
Sounds like CTags/Tagmanager could just store a character number field rather than actually *replacing* tagmanager.
But I'm not sure it's really worth it - can you show a usual code sample where we actually want to show things in the symbol list that are on the same line number which have the same name?
Nick
Hi Nick,
On 14 April 2012 02:35, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 11/04/2012 01:50, Lex Trotman wrote:
I notice that docbook isn't highlighted, should we make it use the Scintilla XML lexer? (since all the docbook I have is machine generated it has the extension xml any way so I had to set it to docbook)
It was highlighted before, looks like it got broken in the highlightingmappings.h change. One problem is the filetype file uses [styling=XML], which is recursive so should be =HTML. Another is that the style strings in the header don't match. I've fixed these locally but I'm not yet sure if docbook styling needs to be separate.
You lost me there, maybe Colomban would know better.
[...]
Sounds like CTags/Tagmanager could just store a character number field rather than actually *replacing* tagmanager.
I think I answered your specific question, rather than the real one, "why replace tagmanager" for which these things are only part of the problem.
IIUC two main reasons:
1. its inefficient, it sorts the symbol list each time it adds one. That was ok when tag lists were small and loaded once in a blue moon, but now loading tags for some of the big libraries around today is causing startup delays (see various ML/IRC complaints) and with real-time(ish) parsing it causes interrupts to the UI for big files, and if we were to fix it to parse the insides of functions (which we really need to do to take proper advantage of your scope autocompletion) then it will be worse.
2. it is difficult to maintain and to fix the above and the other little problems. Nobody with the project properly understands tagmanager and is willing/has time to make the changes. So (putting words in his mouth which he might spit out :) I guess Colomban chose to spend his time re-implementing it so he knows he can make the changes needed (or make them during design rather than retrofitting them) rather than spend his time hacking on code he really didn't understand and might not be able to fix.
But I'm not sure it's really worth it - can you show a usual code sample where we actually want to show things in the symbol list that are on the same line number which have the same name?
Humans probably don't, but I was talking about XML and machine generated XML often puts multiple tags on the same line (if not the whole file :) and thats just when you *need* assistance from the symbols for structure identification. This is not to be taken as saying it is worth the effort though, as I believe that humans should neither read nor write XML as it is a tool of the devil, but occasionally it is required.
Cheers Lex
Nick _______________________________________________ Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On 14/04/2012 01:29, Lex Trotman wrote:
Hi Nick,
Sounds like CTags/Tagmanager could just store a character number field rather than actually *replacing* tagmanager.
I think I answered your specific question, rather than the real one, "why replace tagmanager" for which these things are only part of the problem.
IIUC two main reasons:
- its inefficient, it sorts the symbol list each time it adds one.
That was ok when tag lists were small and loaded once in a blue moon, but now loading tags for some of the big libraries around today is causing startup delays (see various ML/IRC complaints) and with real-time(ish) parsing it causes interrupts to the UI for big files, and if we were to fix it to parse the insides of functions (which we really need to do to take proper advantage of your scope autocompletion) then it will be worse.
- it is difficult to maintain and to fix the above and the other
little problems. Nobody with the project properly understands tagmanager and is willing/has time to make the changes. So (putting
I agree that tagmanager/ctags could use some improvements.
Regarding performance problems with resorting global and workspace tags, I've been working yesterday on improving this significantly by merging the new tags each time instead of resorting *all* the tags. I hope to commit this in the next few days.
words in his mouth which he might spit out :) I guess Colomban chose to spend his time re-implementing it so he knows he can make the changes needed (or make them during design rather than retrofitting them) rather than spend his time hacking on code he really didn't understand and might not be able to fix.
I've just PM'd Colomban so hopefully we can discuss this further.
But I'm not sure it's really worth it - can you show a usual code sample where we actually want to show things in the symbol list that are on the same line number which have the same name?
Humans probably don't, but I was talking about XML and machine generated XML often puts multiple tags on the same line (if not the whole file :) and thats just when you *need* assistance from the symbols for structure identification. This is not to be taken as saying it is worth the effort though, as I believe that humans should neither read nor write XML as it is a tool of the devil, but occasionally it is required.
Unfortunately recording the column/position of each tag might require non-trivial changes to every parser, not just to ctags/tagmanager/geany. But Colomban may have a solution.
Regards, Nick
On 13/04/2012 17:35, Nick Treleaven wrote:
On 11/04/2012 01:50, Lex Trotman wrote:
I notice that docbook isn't highlighted, should we make it use the Scintilla XML lexer? (since all the docbook I have is machine generated it has the extension xml any way so I had to set it to docbook)
It was highlighted before, looks like it got broken in the highlightingmappings.h change. One problem is the filetype file uses [styling=XML], which is recursive so should be =HTML. Another is that the style strings in the header don't match. I've fixed these locally but I'm not yet sure if docbook styling needs to be separate.
Now fixed in Git, thanks for reporting. It was actually the common styling change rather than Colomban's mapping change that broke it.
Regards, Nick
Hi,
Thank you very much for your help and thoughts, and sorry for the slow reply. See my comments inline.
On Wed, Apr 11, 2012 at 2:50 AM, Lex Trotman elextr@gmail.com wrote:
On 11 April 2012 02:23, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 10/04/2012 09:57, Lex Trotman wrote:
On 10 April 2012 18:14, Robert Feketefekete77.robert@gmail.com wrote:
- Is it possible to list the symbols by appearance by default?
Currently I have to manually change this setting for every file.
Well, for most programming, having the symbols in alphabetical order is the right thing to do, so thats the default. As you noted it is a per-file setting and there is no way to store it per file. Making the default per filetype might be your solution, but that would take some work and well, somebodys got to do it. But patches are welcome.
Already implemented per-filetype - see symbol_list_sort_mode under: http://www.geany.org/manual/current/index.html#settings-section
Thanks Nick, missed it.
It's the default for e.g. reStructuredText and could be for DocBook if that seems sensible.
Yes, Docbook users should decide, or Robert can just change his own Docbook filetype for now.
That is just what I was looking for, I'll change it locally, no problem.
I notice that docbook isn't highlighted, should we make it use the Scintilla XML lexer? (since all the docbook I have is machine generated it has the extension xml any way so I had to set it to docbook)
Geany highlighted docbook files fine, but that got broken some time last year, IIRC. Now with my current build (version 0.21, built from source) it works fine again.
- The symbol tab now shows the sections and chapters in a separate
list, and that way the hierarchy of the tags (the structure of the file) is lost. It is possible to display the list in a tree?
The current tagmanager code is not very good at hierarchy handling (although it does it, it isn't good) and there is work under way to replace it. Until then I would say the answer is theoretically yes
Is there? By who? Surely it would still need to parse tags with the CTags parsers even if it's managed differently than TagManager.
Columban is doing some work on it as he gets time and yes his current intention is to re-use the current parsers (at least when I asked a couple of weeks ago).
Also not sure what you mean by tagmanager not being good at hierarchies.
Well, to be explicit I guess its more to do with the problems with repeated names (although Colombans recent patch has greatly improved it). At the moment the docbook parser uses the id as the unique key and only shows entities with an id, but not all entities must have an ID. To show the entire hierarchy it would have repeated <chapter> and especially <section> <paragraph> etc it is going to need a better "uniquification" of the repeated name. Colomban uses line number to uniquify the key, but with XML you often get multiple things on a line so something else is needed, eg character number.
ID is entirely optional in docbook. What would be useful in these situations is the content of the <title> tag of the element, but that would probably require Geany to parse the file with an XML parser, because the title tag is not necessarily in the same line as its parent tag (though usually it is the first child node).
On the other hand, I think it would not be necessary to show every element in the sidebar hierarchy: for a start, "main" elements and their titles/ids would be great. Under main elements I mean nodes like chapter, section, procedure, and so on, that give the main structure of the file.
Have a nice weekend!
Regards,
Robert
Cheers Lex
Regards, Nick
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany