On 26 May 2014 09:10, Matthew Brush wrote:
> Hi,
>
> If nobody's opposed to this, then I'll start working on it shortly. At worst
> we'll end up with some new `*private.h` files in the `src` directory and
> maybe find some buggy plugins and/or unintentionally-public API.
>
> I'll try to keep the p
On 14-05-25 05:16 PM, Lex Trotman wrote:
On 26 May 2014 09:38, Matthew Brush wrote:
[snip]
Another example is `filetype_id` which is the enum type in `filetypes.h`
that holds the various filetype IDs (ex. GEANY_FILETYPES_C,
GEANY_FILETYPES_HTML, etc.). It's completely undocumented, but is used
On 26 May 2014 10:19, Matthew Brush wrote:
> On 14-05-25 04:38 PM, Matthew Brush wrote:
>>
>> [snip]
>>
>> And my final question: do we support individual includes of Geany's
>> headers that were available? For example, if someone, for some crazy
>> reason wanted to move `struct GeanyDocument` to
On 14-05-25 05:23 PM, Lex Trotman wrote:
On 26 May 2014 09:50, Matthew Brush wrote:
[snip]
If we moved to having public headers that just included actual public
symbols, I think it would be advantageous to have those headers totally
commented/documented rather than requiring the user to downlo
On 26 May 2014 09:50, Matthew Brush wrote:
> Hi,
>
> As part of working on cleaning up the exposed API to plugins I got to
> thinking about where our comments are located. While it's nice to keep the
> API-documentation-comments right at the definitions of the functions in
> their respective .c so
On 14-05-25 04:38 PM, Matthew Brush wrote:
[snip]
And my final question: do we support individual includes of Geany's
headers that were available? For example, if someone, for some crazy
reason wanted to move `struct GeanyDocument` to `document-blah.h` (fake
example), is it a plugin bug if they d
On 26 May 2014 09:38, Matthew Brush wrote:
> Hi,
>
> Is it fair to say that any function that is not represented in
> `geanyfunctions.h`/`plugindata.h` and any types that are not documented with
> a `/**` or other Doxygen comment are to be considered "private" with respect
> to the plugin API?
My
Hi,
As part of working on cleaning up the exposed API to plugins I got to
thinking about where our comments are located. While it's nice to keep
the API-documentation-comments right at the definitions of the functions
in their respective .c source files, since we only install the headers
as a
Hi,
Is it fair to say that any function that is not represented in
`geanyfunctions.h`/`plugindata.h` and any types that are not documented
with a `/**` or other Doxygen comment are to be considered "private"
with respect to the plugin API?
For example there are some types/enums in `build.h`
Hi,
If nobody's opposed to this, then I'll start working on it shortly. At
worst we'll end up with some new `*private.h` files in the `src`
directory and maybe find some buggy plugins and/or
unintentionally-public API.
I'll try to keep the private headers changes separate from the removal
o
On Sat, 24 May 2014 11:55:47 +0200
Enrico Tröger wrote:
> On 18/05/14 19:08, Dimitar Zhekov wrote:
> > On Sun, 18 May 2014 15:30:21 +0200
> > Enrico Tröger wrote:
> >
> >> On 16/05/14 18:41, Dimitar Zhekov wrote:
> >>>
> >>> The prefix problem is workarounded. Since geany.pc is installed in
> >
11 matches
Mail list logo
