I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
Cheers Lex
On 25 February 2012 08:01, Frank Lanitz git-noreply@geany.org wrote:
Branch: refs/heads/master Author: Frank Lanitz frank@frank.uvena.de Committer: Frank Lanitz frank@frank.uvena.de Date: Fri, 24 Feb 2012 21:01:08 Commit: 795ee4cf4bea525814b5793a6771d3da78f6c863 https://github.com/geany/geany/commit/795ee4cf4bea525814b5793a6771d3da78f6c8...
Log Message:
Merge pull request #28 from RetroX/patch-1
Added size_t, ptrdiff_t, intN_t to filetypes.cpp.
Modified Paths:
data/filetypes.cpp
Modified: data/filetypes.cpp 2 files changed, 1 insertions(+), 1 deletions(-) =================================================================== @@ -3,7 +3,7 @@
[keywords] # all items must be in one line -primary=alignas alignof and and_eq asm auto bitand bitor bool break case catch char char16_t char32_t class compl const constexpr const_cast continue decltype default delete do double dynamic_cast else enum explicit export extern false final float for friend goto if inline int long mutable namespace new noexcept not not_eq nullptr operator or or_eq override private protected public register reinterpret_cast return short signed sizeof static static_assert static_cast struct switch template this thread_local throw true try typedef typeid typename union unsigned using virtual void volatile wchar_t while xor xor_eq +primary=alignas alignof and and_eq asm auto bitand bitor bool break case catch char char16_t char32_t class compl const const_cast constexpr continue decltype default delete do double dynamic_cast else enum explicit export extern false final float for friend goto if inline int int8_t int16_t int32_t int64_t long mutable namespace new noexcept not not_eq nullptr operator or or_eq override private protected ptrdiff_t public register reinterpret_cast return short signed sizeof size_t static static_assert static_cast struct switch template this thread_local throw true try typedef typeid typename union unsigned using virtual void volatile wchar_t while xor xor_eq secondary= # these are some doxygen keywords (incomplete) docComment=attention author brief bug class code date def enum example exception file fn namespace note param remarks return see since struct throw todo tparam typedef var version warning union
This E-Mail was brought to you by github_commit_mail.py (Source: TBD). _______________________________________________ Geany-commits mailing list Geany-commits@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Best regards.
On 25 February 2012 09:44, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Yes, good idea, if I understand the comment in highlightingmappings.h:206 it is meant for types.
Cheers Lex
PS the existing list contains the fundamental types that are always available without headers, these new ones need a header (though size_t is used so much that almost any header will do :)
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 25 Feb 2012 10:43:10 +1100 Lex Trotman elextr@gmail.com wrote:
On 25 February 2012 09:44, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Yes, good idea, if I understand the comment in highlightingmappings.h:206 it is meant for types.
Cheers Lex
PS the existing list contains the fundamental types that are always available without headers, these new ones need a header (though size_t is used so much that almost any header will do :)
I did like that idea adding more often used one. But you are right cleaning up a bit and maybe resorting them would be might a ice idea.
Cheers, Frank
On 25 February 2012 19:35, Frank Lanitz frank@frank.uvena.de wrote:
On Sat, 25 Feb 2012 10:43:10 +1100 Lex Trotman elextr@gmail.com wrote:
On 25 February 2012 09:44, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Yes, good idea, if I understand the comment in highlightingmappings.h:206 it is meant for types.
Cheers Lex
PS the existing list contains the fundamental types that are always available without headers, these new ones need a header (though size_t is used so much that almost any header will do :)
I did like that idea adding more often used one. But you are right cleaning up a bit and maybe resorting them would be might a ice idea.
Cheers, Frank
Hi Frank,
I think Thomas' idea of adding those that are not fundamental types to the secondary list is the right thing, they get highlighted as types not keywords and as you say the common ones are then available. Best of both worlds :).
I think all the ones that were originally in the list were fundamental in C++11, so its only the new ones IIUC.
I was going to do it today but havn't had time.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 25.02.2012 09:55, schrieb Lex Trotman:
On 25 February 2012 19:35, Frank Lanitzfrank@frank.uvena.de wrote:
On Sat, 25 Feb 2012 10:43:10 +1100 Lex Trotmanelextr@gmail.com wrote:
On 25 February 2012 09:44, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Yes, good idea, if I understand the comment in highlightingmappings.h:206 it is meant for types.
Cheers Lex
PS the existing list contains the fundamental types that are always available without headers, these new ones need a header (though size_t is used so much that almost any header will do :)
I did like that idea adding more often used one. But you are right cleaning up a bit and maybe resorting them would be might a ice idea.
Cheers, Frank
Hi Frank,
I think Thomas' idea of adding those that are not fundamental types to the secondary list is the right thing, they get highlighted as types not keywords and as you say the common ones are then available. Best of both worlds :).
I think all the ones that were originally in the list were fundamental in C++11, so its only the new ones IIUC.
My idea was adding *all* types to secondary. Why differentiate between fundamental/"needs header" and others? The important point is they are types and not keywords.
Best regards.
On 25 February 2012 20:03, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 25.02.2012 09:55, schrieb Lex Trotman:
On 25 February 2012 19:35, Frank Lanitzfrank@frank.uvena.de wrote:
On Sat, 25 Feb 2012 10:43:10 +1100 Lex Trotmanelextr@gmail.com wrote:
On 25 February 2012 09:44, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 24.02.2012 23:34, schrieb Lex Trotman:
I don't agree with this change, the types are just that, types, not keywords, they should not be highlighted as keywords. They are not always available. This change should be reverted.
The list contained types before the commit and the commit just added more for completeness.
I suggest using the secondary for types instead.
Yes, good idea, if I understand the comment in highlightingmappings.h:206 it is meant for types.
Cheers Lex
PS the existing list contains the fundamental types that are always available without headers, these new ones need a header (though size_t is used so much that almost any header will do :)
I did like that idea adding more often used one. But you are right cleaning up a bit and maybe resorting them would be might a ice idea.
Cheers, Frank
Hi Frank,
I think Thomas' idea of adding those that are not fundamental types to the secondary list is the right thing, they get highlighted as types not keywords and as you say the common ones are then available. Best of both worlds :).
I think all the ones that were originally in the list were fundamental in C++11, so its only the new ones IIUC.
My idea was adding *all* types to secondary. Why differentiate between fundamental/"needs header" and others? The important point is they are types and not keywords.
Ok, I don't mind either way, just was retaining backward compatibility.
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Thomas Martitz wrote:
My idea was adding *all* types to secondary. Why differentiate between fundamental/"needs header" and others? The important point is they are types and not keywords.
+!
Erik
On Sat, 25 Feb 2012 10:03:39 +0100 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
My idea was adding *all* types to secondary. Why differentiate between fundamental/"needs header" and others? The important point is they are types and not keywords.
+1
Hi All,
I have thought about which types should be "automagically" present in Geany without a tags file, and I do not think the intN_t types qualify. They are not fundamental, they require header <cstdint> to be included and they do not even have to exist, they are all optional, only the fast and least types are required, and they don't have fixed sizes.
Also it is bad practice to be using fixed size types, especially as they are not actually guaranteed to exist. If they are used they should be typedefed to a more user friendly name.
So I suggest that only the fundamental types and <cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Regards Lex
Lex Trotman wrote:
I have thought about which types should be "automagically" present in Geany without a tags file, and I do not think the intN_t types qualify. They are not fundamental,
In C99 they are.
they require header <cstdint> to
Thats C++. I'm pretty sure all the C99 intN_t types were added to the latest C++ standard as well.
Also it is bad practice to be using fixed size types, especially as they are not actually guaranteed to exist.
All compliant C99 implementations *must* provide the standard intN_t types.
If they are used they should be typedefed to a more user friendly name.
I am sure I am not the only one who considers
typedef int32_t my_project_int16_t ;
to be bad practice.
So I suggest that only the fundamental types and <cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Please do not conflate C++ with C.
Erik
Le 26/02/2012 00:31, Erik de Castro Lopo a écrit :
Lex Trotman wrote:
[...]
If they are used they should be typedefed to a more user friendly name.
I am sure I am not the only one who considers
typedef int32_t my_project_int16_t ;to be bad practice.
+1
So I suggest that only the fundamental types and <cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Please do not conflate C++ with C.
hum:
On 25 February 2012 08:01, Frank Lanitz git-noreply@geany.org wrote:
[...]
Modified Paths:
data/filetypes.cpp
Maybe you're confounding? :)
Cheers, Colomban
On 26 February 2012 10:31, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
I have thought about which types should be "automagically" present in Geany without a tags file, and I do not think the intN_t types qualify. They are not fundamental,
In C99 they are.
they require header <cstdint> to
Thats C++. I'm pretty sure all the C99 intN_t types were added to the latest C++ standard as well.
The changes we are talking about are to filetypes.cpp which is c++
The intN_t types are in <cstdint> header, they are not fundamental and as I said they are not required.
Also it is bad practice to be using fixed size types, especially as they are not actually guaranteed to exist.
All compliant C99 implementations *must* provide the standard intN_t types.
No, they are optional in C as well, an implementation on an embedded processor does *not* have to supply a fixed width twos complement 64 bit type unless it happens to have one. A processor does not have to address 8 bits, it could address 16 bits in which case int8_t won't exist.
If they are used they should be typedefed to a more user friendly name.
I am sure I am not the only one who considers
typedef int32_t my_project_int16_t ;
to be bad practice.
Indeed, but it is good practice to typedef uint8_t to octet to represent utf8 octets instead of splattering uint8_ts everywhere, thats what I mean.
So I suggest that only the fundamental types and <cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Please do not conflate C++ with C.
As I said the changes were to filetypes.cpp which is the C++ filetype file. I mentioned in a previous post that something similar should be done to the C types, but that isn't the current point.
Cheers Lex
Lex Trotman wrote:
On 26 February 2012 10:31, Erik de Castro Lopo mle+tools@mega-nerd.com wrote:
Lex Trotman wrote:
I have thought about which types should be "automagically" present in Geany without a tags file, and I do not think the intN_t types qualify. They are not fundamental,
In C99 they are.
they require header <cstdint> to
Thats C++. I'm pretty sure all the C99 intN_t types were added to the latest C++ standard as well.
The changes we are talking about are to filetypes.cpp which is c++
My apologies. I came in to the middle of this thread and missed the context.
Erik
Am 26.02.2012 00:26, schrieb Lex Trotman:
So I suggest that only the fundamental types and<cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Why does it matter whether they are fundamental types or not important? The point is they are types and keywords.
Best regards.
On 28 February 2012 21:04, Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 26.02.2012 00:26, schrieb Lex Trotman:
So I suggest that only the fundamental types and<cstddef> types size_t, nullptr_t ptrdiff_t and max_align_t should be available by adding them to the secondary keyword list for C++.
Why does it matter whether they are fundamental types or not important? The point is they are types and keywords.
Yes, types go in the secondary list, keywords go in the primary list.
The point is where do we stop adding things to the secondary list and say you have to load tags to get them?
The list in the filetype file should be the minimum:
1. fundamental types which you can't get from tags since they are not in headers 2. the <cstddef> types since they are used nearly everywhere.
All others should be added by tags allowing the user to choose which they need.
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel