Skip to content

Commit

Permalink
.dir-locals.el: add dir-locals for Emacs
Browse files Browse the repository at this point in the history 
Signed-off-by: Maciej Barć <xgqt@riseup.net>
  • Loading branch information
Maciej Barć committed May 16, 2021
1 parent 099b467 commit 926e90a
Showing 1 changed file with 14 additions and 0 deletions.
14 changes: 14 additions & 0 deletions .dir-locals.el
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
(
(find-file
. (
(require-final-newline . t)

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

.editorconfig already sets that. You can use it with the editorconfig mode.
(show-trailing-whitespace . t)
(tab-width . 4)

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

.editorconfig already sets that. You can use it with the editorconfig mode.

This comment has been minimized.

Sign in to view

Copy link
@xgqt

xgqt May 17, 2021

Member

somebody could be using vanilla emacs w/o external pkgs

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

It doesn't really matter if my editor shows the tabs as 4 spaces long, 2 spaces long or 8 spaces long.
)
)
(ebuild-mode
. (
(indent-tabs-mode . t)

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

ebuild-mode already sets that.

This comment has been minimized.

Sign in to view

Copy link
@xgqt

xgqt May 17, 2021

Member

oh yea, I forgot that I wanted to correct that to force it on .ebuild and .eclass files in case somebody doesnt have ebuild-mode

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

I'm pretty sure repoman will warn if there are spaces as indentation in ebuilds? I think this goes for newlines at EOF too.

This comment has been minimized.

Sign in to view

Copy link
@xgqt

xgqt May 17, 2021

Member

I'm pretty sure repoman will warn if there are spaces as indentation in ebuilds? I think this goes for newlines at EOF too.

yes, it probably would warn, but you would like to have this enforced while editing a file instead after of having to revisit it and correct your editing mistakes, no?

This comment has been minimized.

Sign in to view

Copy link
@xgqt

xgqt May 17, 2021

Member

oh yea, I forgot that I wanted to correct that to force it on .ebuild and .eclass files in case somebody doesnt have ebuild-mode

btw any idea how to do this?

This comment has been minimized.

Sign in to view

Copy link
@tastytea

tastytea May 17, 2021

Contributor

oh yea, I forgot that I wanted to correct that to force it on .ebuild and .eclass files in case somebody doesnt have ebuild-mode

btw any idea how to do this?

I don't think there is a ebuild writer using Emacs that doesn't have it installed? If there is one, they should be told to install it.

This comment has been minimized.

Sign in to view

Copy link
@xgqt

xgqt May 17, 2021

Member

oh yea, I forgot that I wanted to correct that to force it on .ebuild and .eclass files in case somebody doesnt have ebuild-mode

btw any idea how to do this?

I don't think there is a ebuild writer using Emacs that doesn't have it installed? If there is one, they should be told to install it.

probably, but still one could use just plain shell-mode in .ebuild files
)
)
)

7 comments on commit 926e90a

@tastytea
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these kind of changes should be discussed beforehand, since it alters the behavior of Emacs for everyone. Or did I miss the discussion?

@xgqt
Copy link
Member

@xgqt xgqt commented on 926e90a May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these kind of changes should be discussed beforehand, since it alters the behavior of Emacs for everyone. Or did I miss the discussion?

the same rules are set in .editorconfig, no?

@tastytea
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the same rules are set in .editorconfig, no?

Yes, apart from show-trailing-whitespace, which I don't mind.
However, users may wish to use a local .dir-locals.el, to set some magit variables or bug-reference-url-format or whatever.

@xgqt
Copy link
Member

@xgqt xgqt commented on 926e90a May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to set some magit variables

would be nice if those too could be "generalized" and used by more people

@tastytea
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice if those too could be "generalized" and used by more people

I don't think everyone will agree what the right values are. magit-todos-depth (a variable I set for ::gentoo and may have to set for ::guru too if it gets much larger) for example is not marked safe by default, so everyone would get warnings when entering the directory. Some people may want to set environment variables unique to their workflow. My point is that .dir-locals.el should be local.

@xgqt
Copy link
Member

@xgqt xgqt commented on 926e90a May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice if those too could be "generalized" and used by more people

I don't think everyone will agree what the right values are. magit-todos-depth (a variable I set for ::gentoo and may have to set for ::guru too if it gets much larger) for example is not marked safe by default, so everyone would get warnings when entering the directory. Some people may want to set environment variables unique to their workflow. My point is that .dir-locals.el should be local.

ok! good point

@xgqt
Copy link
Member

@xgqt xgqt commented on 926e90a May 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, thx @tastytea now I understand this was a bad idea

Please sign in to comment.