On 02/07/2012 10:00 PM, Lex Trotman wrote:
On 8 February 2012 03:29, spir<[email protected]> wrote:
On 02/06/2012 09:11 PM, Lex Trotman wrote:
PS Note there is a wiki entry on configuring the build system at
http://wiki.geany.org/howtos/configurebuildmenu
First, thank you and bravo for this wiki page on the topic. It is great and
above all clear. Reading it not only helped but also launched a few comments
to possibly still ameliorate the system on details, and a 2 questions on
remaining obscure points.
If ever I finally understand things well enough, I'll help and improve the
wiki page.
Yes, please help explaining, but please check proposed changes here
first, it annoys the wiki administrator having to revert erroneous
changes.
Right. Anyway i need to be sure i understand properly.
Also add one on settings for Go, and possibly a general one on
how to introduce a new language (this badly lacks in geany doc).
New wiki pages are welcome.
Right (they don't break existing stuff ;-)
*** Questions ***
[... all fine, thanks for your clear answers ...]
*** Comments ***
* Build Menu orga
It may be reorganised so that the 3 configurable sections (out of 5) come
1st, 2nd, 3rd. And --is it possible to have a bigger separation with the
other 2 sections?
The organisation has been the same for a long time, you would have to
have a good argument to change it. (and probably expect to be flamed
on the ML, users get *so* attached to their GUIs) I wasn't around when
it was first proposed, but as I say in the wiki, I believe it is laid
out in the order of the usual C workflow, compile/link one file, make
a whole lot of files, search for the errors, execute the result if no
errors. And prefs is last as usual.
Right.
* No dealing with system config
The user ideally should not have to deal at all with system-general config
files, which also deal as geany defaults IIUC.
Possible solution: In the latest versions, there are entries in the 'Tools'
menu to allow editing some config files directly in geany itself. One of
this entries allows editing filetypes.common; if the user version does not
yet exist (in the user config folder), it is then created by copy (from the
system config folder). Add one entry to edit user filetype config files. Do
the same as for filetypes.common. To select the filetype: (1) a submenu like
for setting the filetype (2) a popup with a rolling list (3) a popup with a
text field to type the (case-insensitive) filetype name.
Yes, extending the menu to the other config files is likely to be
useful, patches welcome.
This would be very nice.
* Easy config of new filetype
This would deal as recommended way to create a *new* filetype: open an
existing one for edition in geany, save it at once as config file for the
new filetype, edit it. There should be a standard one having the structure
and entries with common sensible values, for cases when no appropriate model
filetype exists (present filetypes.Geany.conf seems to be configured for
Vala). Entries for which no sensible value exist should be present anyway,
so that the user knows about them.
> 1. if making a custom filetype (which is based on an existing one)
you would copy the existing filetype as a start
> 2. if making a completely new filetype there is no prototype, it
depends on what capabilities the lexer in Scintilla exposes and how they
are mapped to the config file.
Sorry, I was unclear. I was referring to the point above, the ability to
edit filetype config files from within geany, with transparent copy to
the user config dir if not yet existing:
To create a new filetype, it is clearly good practice to copy from an
existing one. Instead of explicitely copying from the system-wide config
files, as we do now, using the above feature we could just open the
existing filetype config file inside geany, and save it under the proper
name for the new filetype. (The only issue beeing the difference in
naming scheme for custom filetypes, evoked below, but that's independent.)
* No "filetypes.Lang.conf"
Filetype config files should all have the same naming pattern. For a new
language, instead of filetypes.Lang.conf, why not just filetypes.lang? In
addition, having the name capitalised only for new filetypes is a source of
annoying issues.
You can call your custom language anything, up to you, but since it is
displayed it is better to use a name with capitalisation. For builtin
types there is an internal mapping to the displayname, so they use
lower case, but for custom filetypes it always has to be the same so
that Geany can relate settings in filetypes.extensions to the language
etc.
Right.
Custom filetypes have a conf extension so that they get the right
filetype (.conf) when opened by Geany. It would be nice if the
built-in filetypes did the same, I am often annoyed by Geany trying to
format filetypes.c as a C file, but it would be hard to change and
remain backwardly compatible with all the existing edited
filetypes.lang files in user directories.
Right ;-)
* Filetype config file names
Better, also solve this: filetype config files are often edited in geany
(else, other editors also have styling for common languages). Since the
names of the config files end in the name of the languge, thjey are styled
as if they were source code of this language, instead of just config files.
Solution: reverse the logic, or rather reset it as should be: lang.cfg
instead of filetypes.lang.
See above.
Pleased to see I'm not the only one.
* no tweaking of filetype_extensions.conf
Filetype extensions should be declared in the filetype config file.
You find the config file by looking up the language name in
filetype_extensions.conf. Geany does *not* read all the language
definition files, only the ones needed for open files.
Actually, all the config for a filetype should be in a single file. I first
thought there could be no filetype_extensions.conf at all, but this may
force geany to read all filetype confg files at startup. Instead, there
could a generated one, updated when filetype config files are edited in
geany, or whenever geany detects a modif (by last edition time), or via the
menu entry "Tools/Reload Configuration".
This would still require Geany to look at all the config files to see
which ones had changed, ok its stating it not loading it, but you
would have to keep doing it.
Is it a big deal at startup to review the time stamps of files
filetypes.* in ~/.config/geany/filedefs, and extract an "extension=*.x"
line for the ones having changed? (I'm really asking, not making bad
spirit.)
Since I'm learning Go, I may find the time to do it as an exercise, i
have not yet touched the os or fs packages ;-) (You would just have to
translate back the routine to C or c++ --I don't even know in what lang
geany is coded!)
* config file doc
Comments in config files may be rewtritten (they have improved, but
still..).
Patches are welcome :)
Some param names can be clearer. (Naming is doc.)
Provide suggestions, being aware that backward compatibility needs to
be kept as much as possible.
You know, I have stopped to do that for a while already, because it is
depressive experience to do sincere and durable efforts for the common
good (after such suggestions as yours) and never see your work into the
product, or 1% of it, or 3 years later. Guess you see what I mean...
Reason why I love wikis. Geany's doc could be a wiki --not only
additional texts such as your guide for the build menu. But it's only
me, indeed.
Denis
_______________________________________________
Geany mailing list
[email protected]
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
