On Fri, 26 Dec 2014 11:42:32 +0100
Markus Wichmann wrote:
Hey Markus,
> I'm talking about stuff like musl: I don't want to know that qsort() is
> defined in src/stdlib/sort.c. I just want to see the function. And if
> you're used to getting that in an instant, manually navigating it is
> just te
On Fri, Dec 26, 2014 at 10:24:27AM +0100, FRIGN wrote:
> no matter how big the codebase is, in my opinion, if you need tools like
> that there's something wrong with the code. And I've worked with really
> big codebases (good and bad) in my time.
I'm talking about stuff like musl: I don't want to
On Fri, 26 Dec 2014 10:24:27 +0100
FRIGN wrote:
(...)
> Modularity in general is what C is about and there's no reason NOT to have
> a very complex problem separated into several smaller problems instead
> of writing one single big monolith you need ctags for to navigate.
sorry, forgot a word t
On Fri, 26 Dec 2014 09:59:02 +0100
Markus Wichmann wrote:
Hey Markus,
> ctags tells me the place where all the functions are defined. It also
> tells me where all the defines are and where all the structure members
> are. It tells me the location of the tag types and the typedefs and so
> on. Al
On Thu, Dec 25, 2014 at 04:02:35PM +0100, k...@shike2.com wrote:
> I don't use ctags. It's simple, if you use the correct code style you don't
> need aditional tools.
>
ctags tells me the place where all the functions are defined. It also
tells me where all the defines are and where all the struc
> Who here doesn't use ctags or similar? Because using navigation
> techniques that only work if not technically enforced style guidelines
> are followed is not really helpful to people who read and write code in
> many different projects.
I don't use ctags. It's simple, if you use the correct co
On Wed, 24 Dec 2014 09:27:02 +0100
Markus Wichmann wrote:
> Basing style guidelines on navigation techniques strikes me as odd.
> Style is only there to ease reading and understanding of the code.
Yup, I agree with you there. The ^Ifun is just ridiculous. The only
really good way I know is using
On Tue, Dec 23, 2014 at 08:42:18AM -0700, Anthony J. Bentley wrote:
> The point of this rule is not visual alignment. Width of the type doesn't
> matter; it is always one tab. The advantage is that you can find the
> declaration of member foo by grepping for ^Ifoo.
>
> Similarly, the "function nam
On Tue, Dec 23, 2014, at 10:42 AM, Anthony J. Bentley wrote:
> The point of this rule is not visual alignment. Width of the type doesn't
> matter; it is always one tab. The advantage is that you can find the
> declaration of member foo by grepping for ^Ifoo.
That violates the suckless style guide
Dimitris Papastamos writes:
> On Tue, Dec 23, 2014 at 04:11:16PM +0100, k...@shike2.com wrote:
> >
> > >> The style(9)-changes were absolutely necessary and it's better to do thi
> s
> > >> as early as possible instead of waiting and waiting until it's too late
> > >> and you have a really big num
On Tue, Dec 23, 2014 at 04:11:16PM +0100, k...@shike2.com wrote:
>
> >> The style(9)-changes were absolutely necessary and it's better to do this
> >> as early as possible instead of waiting and waiting until it's too late
> >> and you have a really big number of patches for a given program.
> >
>> The style(9)-changes were absolutely necessary and it's better to do this
>> as early as possible instead of waiting and waiting until it's too late
>> and you have a really big number of patches for a given program.
>
> The thing I dislike most about the style changes is the alignment of
> va
On Tue, Dec 23, 2014 at 10:28:40AM +0100, FRIGN wrote:
> I hope you saw these patches are for dmenu, not dwm. However, your
> arguments still apply because there is a small set of patches for dmenu.
Ah, you're right. I _did_ think this was for dwm; my mistake.
> Still, for the sake of preserving
On 23 December 2014 at 10:34, FRIGN wrote:
> On Tue, 23 Dec 2014 10:28:36 +0100
> Anselm R Garbe wrote:
>
>> @FRIGN: I'm considering to apply your patches, with the exception
>> outlined of patch 4 line 41-70.
>
> I'm okay with that. ;)
> Do you want me to send you an updated patch 4 or are you a
On Tue, 23 Dec 2014 10:28:36 +0100
Anselm R Garbe wrote:
Hey Anselm,
> @FRIGN: I'm considering to apply your patches, with the exception
> outlined of patch 4 line 41-70.
I'm okay with that. ;)
Do you want me to send you an updated patch 4 or are you able to
manually merge them into the codebas
On 23 December 2014 at 01:10, Eric Pruitt wrote:
> On Mon, Dec 22, 2014 at 06:40:59PM +0100, FRIGN wrote:
>> PATCH 4: As already discussed style(9) is the reference for future code
>> changes. Given the codebase hasn't already been transformed, I
>> did it.
>
> Although I think s
On Mon, 22 Dec 2014 16:10:05 -0800
Eric Pruitt wrote:
Hey Eric,
> Although I think sticking to a specific style going forward is
> reasonable (even if I'm not fond of all of the recommendations of
> style(9)), I don't think refactoring the existing dwm codebase purely
> for style is a good idea.
On Mon, Dec 22, 2014 at 06:40:59PM +0100, FRIGN wrote:
> PATCH 4: As already discussed style(9) is the reference for future code
> changes. Given the codebase hasn't already been transformed, I
> did it.
Although I think sticking to a specific style going forward is
reasonable (e
Good evening,
I sat down this afternoon to read through the dmenu-code and noticed
some things that I fixed with attached patches.
PATCH 1: Use estrtol instead of atoi to make input-checks more thorough
PATCH 2: Un-boolify according to what I already did in some other repos
PATCH 3: config.def.h
19 matches
Mail list logo
