Re: [dev] [surf] tabs and clipboard
Greetings. On Sun, 04 Jan 2015 09:01:28 +0100 Markus Teich wrote: > Heyho, > > Dmitrij D. Czarkoff wrote: > > Markus Teich said: > > > I would like to open a link in a new tab with ctrl-button1 instead of > > > opening up > > > a new surf instance outside of tabbed. > > > > You can already do it with ctrl-button2 (middle button/wheel). See > > buttonrelease() in source if you really want to map it to button1. > > Thanks, this works. I just changed one line in buttonrelease(): > > - newwindow(NULL, &arg, e->state & GDK_CONTROL_MASK); > + newwindow(NULL, &arg, 0); > > Now I can open links in the same tab/window with button1 and in a new > tab/window > with ctrl-button1 as I wanted to. Currently surf does open a new tab with the middle mouse click and when you use the context menu with the right mouse click. What you changed removed the possibility to open a new surf window outside of tabbed. What’s the advantage of mapping this to Button1 and where would you put the possibility to open a surf window outside of tab? Sincerely, Christoph Lohmann
Re: [dev] [surf] tabs and clipboard
Christoph Lohmann wrote: > Currently surf does open a new tab with the middle mouse click and when you > use the context menu with the right mouse click. What you changed removed > the possibility to open a new surf window outside of tabbed. > > What’s the advantage of mapping this to Button1 and where would you put the > possibility to open a surf window outside of tab? I am mainly using a Laptop with no external mouse connected, so just touchpad. I don't use the pointer that often (Nearly only to click on links in surf I think). Since I also mostly use mono/fullscreen mode of dwm, opening single Windows with no tabbing capability seems rather useless (more windows in the view, more time spent finding the right one). However when researching some stuff, I sometimes want to open a link in a new instance and since it does not make sense for me to open it in a new window, I want to open it in a new tab. Is this usecase clear enough or should I elaborate more? --Markus
Re: [dev] [surf] tabs and clipboard
Greetings. On Sun, 04 Jan 2015 13:27:08 +0100 Markus Teich wrote: > Christoph Lohmann wrote: > > Currently surf does open a new tab with the middle mouse click and when you > > use the context menu with the right mouse click. What you changed removed > > the possibility to open a new surf window outside of tabbed. > > > > What’s the advantage of mapping this to Button1 and where would you put the > > possibility to open a surf window outside of tab? > > I am mainly using a Laptop with no external mouse connected, so just > touchpad. I > don't use the pointer that often (Nearly only to click on links in surf I > think). Since I also mostly use mono/fullscreen mode of dwm, opening single > Windows with no tabbing capability seems rather useless (more windows in the > view, more time spent finding the right one). However when researching some > stuff, I sometimes want to open a link in a new instance and since it does not > make sense for me to open it in a new window, I want to open it in a new tab. > Is this usecase clear enough or should I elaborate more? I just try to elaborate if it’s useful to have this as default in surf. Most touchpads have a three mouse button emulation by mapping certain parts of it to the mouse buttons. This isn’t an option on your Laptop? This is configured using the »SoftButtonAreas« option in the synaptics driver. Sincerely, Christoph Lohmann
Re: [dev] [surf] tabs and clipboard
Christoph Lohmann wrote: > I just try to elaborate if it’s useful to have this as default in surf. Most > touchpads have a three mouse button emulation by mapping certain parts of > it to the mouse buttons. This isn’t an option on your Laptop? Heyho, As far as I understand, the touchpad can be configured in any way you like with synaptics, but since this would be the only case where I need a middle mouse button and I don't want the „open new single window“ feature, it is most easy for me to patch this one line. To be honest I found it a little surprising and inconsistent when I noticed, that ctrl-button1 (new single window) and context menu -> „open in new window“ (new tab) did something different. Maybe this should be consistent and configurable in config.h? --Markus
[dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
Hello,
I submitted a patch yesterday so that expandtab and tabwidth are set in
config.def.h, but it was complete shit. Discard the other one. This one
should be much better. I had to add arguments to editor_new().
Sorry for yesterday's shitty patch.
---
config.def.h | 3 +++
editor.c | 6 +++---
editor.h | 2 +-
vis.c| 3 +--
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/config.def.h b/config.def.h
index aac28a8..70c1708 100644
--- a/config.def.h
+++ b/config.def.h
@@ -12,6 +12,9 @@
{ { NONE(127) }, (func), { .name = (arg) } }, \
{ { CONTROL('B') }, (func), { .name = (arg) } }
+#define TABWIDTH 8
+#define EXPANDTAB false
+
/* a mode contains a set of key bindings which are currently valid.
*
* each mode can specify one parent mode which is consultated if a given key
diff --git a/editor.c b/editor.c
index ef59242..ae7338f 100644
--- a/editor.c
+++ b/editor.c
@@ -431,7 +431,7 @@ void editor_window_close(EditorWin *win) {
editor_draw(ed);
}
-Editor *editor_new(int width, int height) {
+Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
Editor *ed = calloc(1, sizeof(Editor));
if (!ed)
return NULL;
@@ -441,8 +441,8 @@ Editor *editor_new(int width, int height) {
goto err;
ed->width = width;
ed->height = height;
- ed->tabwidth = 8;
- ed->expandtab = false;
+ ed->tabwidth = tabwidth;
+ ed->expandtab = expandtab;
ed->windows_arrange = windows_arrange_horizontal;
return ed;
err:
diff --git a/editor.h b/editor.h
index 5dcb122..e358923 100644
--- a/editor.h
+++ b/editor.h
@@ -110,7 +110,7 @@ struct Editor {
bool expandtab; /* whether typed tabs should be
converted to spaces */
};
-Editor *editor_new(int width, int height);
+Editor *editor_new(int width, int height, int tabwidth, bool expandtab);
void editor_free(Editor*);
void editor_resize(Editor*, int width, int height);
void editor_draw(Editor*);
diff --git a/vis.c b/vis.c
index 7ccfa22..ee09be6 100644
--- a/vis.c
+++ b/vis.c
@@ -55,7 +55,6 @@ typedef struct {
#define MAX_KEYS 2
typedef Key KeyCombo[MAX_KEYS];
-
typedef struct {
KeyCombo key;
void (*func)(const Arg *arg);
@@ -1886,7 +1885,7 @@ int main(int argc, char *argv[]) {
mode_prev = mode = config->mode;
setup();
- if (!(vis = editor_new(screen.w, screen.h)))
+ if (!(vis = editor_new(screen.w, screen.h, TABWIDTH, EXPANDTAB)))
die("Could not allocate editor core\n");
if (!editor_syntax_load(vis, syntaxes, colors))
die("Could not load syntax highlighting definitions\n");
--
2.2.1
Re: [dev] [surf] tabs and clipboard
Greetings. On Sun, 04 Jan 2015 16:47:09 +0100 Markus Teich wrote: > Christoph Lohmann wrote: > > I just try to elaborate if it’s useful to have this as default in surf. > > Most > > touchpads have a three mouse button emulation by mapping certain parts of > > it to the mouse buttons. This isn’t an option on your Laptop? > > Heyho, > > As far as I understand, the touchpad can be configured in any way you like > with > synaptics, but since this would be the only case where I need a middle mouse > button and I don't want the „open new single window“ feature, it is most easy > for me to patch this one line. To be honest I found it a little surprising and > inconsistent when I noticed, that ctrl-button1 (new single window) and > context menu -> „open in new window“ (new tab) did something different. Maybe > this should be consistent and configurable in config.h? There’s an extra mode other browsers don’t have to care about. Even if it’s fixed in tabbed to have a more dynamic release and addition of tabs the concept of embedding wouldn’t be useful anymore. It’s still under‐ used as it could be. Instead separate sub‐standards evolved in every ap‐ plication. I don’t see any need for further research into this direction as of now to have more embedding everywhere. Separating the button events into config.h should be possible. I would welcome a patch. Sincerely, Christoph Lohmann
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
Heyhey
On Sun, Jan 4, 2015 at 4:42 PM, Matthias Rabault
wrote:
> I submitted a patch yesterday so that expandtab and tabwidth are set in
> config.def.h, but it was complete shit. Discard the other one. This one
> should be much better. I had to add arguments to editor_new().
>
> Sorry for yesterday's shitty patch.
In my opinion making mistakes is okay. You should have read up on how
the C pre-processor works before sending a first patch though.
I have only one comment (inline below).
> ---
> config.def.h | 3 +++
> editor.c | 6 +++---
> editor.h | 2 +-
> vis.c| 3 +--
> 4 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/config.def.h b/config.def.h
> index aac28a8..70c1708 100644
> --- a/config.def.h
> +++ b/config.def.h
> @@ -12,6 +12,9 @@
> { { NONE(127) }, (func), { .name = (arg) } }, \
> { { CONTROL('B') }, (func), { .name = (arg) } }
>
> +#define TABWIDTH 8
> +#define EXPANDTAB false
> +
> /* a mode contains a set of key bindings which are currently valid.
> *
> * each mode can specify one parent mode which is consultated if a given key
> diff --git a/editor.c b/editor.c
> index ef59242..ae7338f 100644
> --- a/editor.c
> +++ b/editor.c
> @@ -431,7 +431,7 @@ void editor_window_close(EditorWin *win) {
> editor_draw(ed);
> }
>
> -Editor *editor_new(int width, int height) {
> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
> Editor *ed = calloc(1, sizeof(Editor));
> if (!ed)
> return NULL;
> @@ -441,8 +441,8 @@ Editor *editor_new(int width, int height) {
> goto err;
> ed->width = width;
> ed->height = height;
> - ed->tabwidth = 8;
> - ed->expandtab = false;
> + ed->tabwidth = tabwidth;
> + ed->expandtab = expandtab;
> ed->windows_arrange = windows_arrange_horizontal;
> return ed;
> err:
> diff --git a/editor.h b/editor.h
> index 5dcb122..e358923 100644
> --- a/editor.h
> +++ b/editor.h
> @@ -110,7 +110,7 @@ struct Editor {
> bool expandtab; /* whether typed tabs should be
> converted to spaces */
> };
>
> -Editor *editor_new(int width, int height);
> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab);
> void editor_free(Editor*);
> void editor_resize(Editor*, int width, int height);
> void editor_draw(Editor*);
> diff --git a/vis.c b/vis.c
> index 7ccfa22..ee09be6 100644
> --- a/vis.c
> +++ b/vis.c
> @@ -55,7 +55,6 @@ typedef struct {
>
> #define MAX_KEYS 2
> typedef Key KeyCombo[MAX_KEYS];
> -
There is no need to remove this empty line in this patch. If you
really want to suggest to do so, send a new patch (but I don't think
such a patch will be very welcome).
> typedef struct {
> KeyCombo key;
> void (*func)(const Arg *arg);
> @@ -1886,7 +1885,7 @@ int main(int argc, char *argv[]) {
> mode_prev = mode = config->mode;
> setup();
>
> - if (!(vis = editor_new(screen.w, screen.h)))
> + if (!(vis = editor_new(screen.w, screen.h, TABWIDTH, EXPANDTAB)))
> die("Could not allocate editor core\n");
> if (!editor_syntax_load(vis, syntaxes, colors))
> die("Could not load syntax highlighting definitions\n");
> --
> 2.2.1
>
>
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
> -Editor *editor_new(int width, int height) {
> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
I am not affiliated with vis or have any familiarity with it
but this doesn't make sense. I'd expect tabwidth/expandtab to be global
variables in this case as they affect global state.
This approach quickly doesn't scale if you want more parameters to
be configured by the user and skews the semantics of the function.
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
Oops ... The empty line removal was an accident. As to yesterday's blunder, I
knew how to use the preprocessor, I was only tired and did everything too fast
...
Silvan Jegen a écrit :
>Heyhey
>
>On Sun, Jan 4, 2015 at 4:42 PM, Matthias Rabault
> wrote:
>> I submitted a patch yesterday so that expandtab and tabwidth are set in
>> config.def.h, but it was complete shit. Discard the other one. This one
>> should be much better. I had to add arguments to editor_new().
>>
>> Sorry for yesterday's shitty patch.
>
>In my opinion making mistakes is okay. You should have read up on how
>the C pre-processor works before sending a first patch though.
>
>I have only one comment (inline below).
>
>> ---
>> config.def.h | 3 +++
>> editor.c | 6 +++---
>> editor.h | 2 +-
>> vis.c| 3 +--
>> 4 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/config.def.h b/config.def.h
>> index aac28a8..70c1708 100644
>> --- a/config.def.h
>> +++ b/config.def.h
>> @@ -12,6 +12,9 @@
>> { { NONE(127) }, (func), { .name = (arg) } }, \
>> { { CONTROL('B') }, (func), { .name = (arg) } }
>>
>> +#define TABWIDTH 8
>> +#define EXPANDTAB false
>> +
>> /* a mode contains a set of key bindings which are currently valid.
>> *
>> * each mode can specify one parent mode which is consultated if a given key
>> diff --git a/editor.c b/editor.c
>> index ef59242..ae7338f 100644
>> --- a/editor.c
>> +++ b/editor.c
>> @@ -431,7 +431,7 @@ void editor_window_close(EditorWin *win) {
>> editor_draw(ed);
>> }
>>
>> -Editor *editor_new(int width, int height) {
>> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
>> Editor *ed = calloc(1, sizeof(Editor));
>> if (!ed)
>> return NULL;
>> @@ -441,8 +441,8 @@ Editor *editor_new(int width, int height) {
>> goto err;
>> ed->width = width;
>> ed->height = height;
>> - ed->tabwidth = 8;
>> - ed->expandtab = false;
>> + ed->tabwidth = tabwidth;
>> + ed->expandtab = expandtab;
>> ed->windows_arrange = windows_arrange_horizontal;
>> return ed;
>> err:
>> diff --git a/editor.h b/editor.h
>> index 5dcb122..e358923 100644
>> --- a/editor.h
>> +++ b/editor.h
>> @@ -110,7 +110,7 @@ struct Editor {
>> bool expandtab; /* whether typed tabs should be
>> converted to spaces */
>> };
>>
>> -Editor *editor_new(int width, int height);
>> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab);
>> void editor_free(Editor*);
>> void editor_resize(Editor*, int width, int height);
>> void editor_draw(Editor*);
>> diff --git a/vis.c b/vis.c
>> index 7ccfa22..ee09be6 100644
>> --- a/vis.c
>> +++ b/vis.c
>> @@ -55,7 +55,6 @@ typedef struct {
>>
>> #define MAX_KEYS 2
>> typedef Key KeyCombo[MAX_KEYS];
>> -
>
>There is no need to remove this empty line in this patch. If you
>really want to suggest to do so, send a new patch (but I don't think
>such a patch will be very welcome).
>
>> typedef struct {
>> KeyCombo key;
>> void (*func)(const Arg *arg);
>> @@ -1886,7 +1885,7 @@ int main(int argc, char *argv[]) {
>> mode_prev = mode = config->mode;
>> setup();
>>
>> - if (!(vis = editor_new(screen.w, screen.h)))
>> + if (!(vis = editor_new(screen.w, screen.h, TABWIDTH, EXPANDTAB)))
>> die("Could not allocate editor core\n");
>> if (!editor_syntax_load(vis, syntaxes, colors))
>> die("Could not load syntax highlighting definitions\n");
>> --
>> 2.2.1
>>
>>
>
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
I see your point and I agree. I didn't think of that, so I'll have to think of
another way to do that, which doesn't change the prototype. Thanks for the
insight !
Dimitris Papastamos a écrit :
>> -Editor *editor_new(int width, int height) {
>> +Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
>
>I am not affiliated with vis or have any familiarity with it
>but this doesn't make sense. I'd expect tabwidth/expandtab to be global
>variables in this case as they affect global state.
>
>This approach quickly doesn't scale if you want more parameters to
>be configured by the user and skews the semantics of the function.
>
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
On Sun, Jan 04, 2015 at 04:37:06PM +, Dimitris Papastamos wrote:
> > -Editor *editor_new(int width, int height) {
> > +Editor *editor_new(int width, int height, int tabwidth, bool expandtab) {
>
> I am not affiliated with vis or have any familiarity with it
> but this doesn't make sense. I'd expect tabwidth/expandtab to be global
> variables in this case as they affect global state.
>
> This approach quickly doesn't scale if you want more parameters to
> be configured by the user and skews the semantics of the function.
I agree that this approach does not scale.
A more scalable approach may be to add tabwidth/expandtab fields to
the Config struct in vis.c and use them to initialize the Editor fields
(through the 'config' global set in main). This approach would probably
require more changes however.
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
On Sun, 04 Jan 2015 17:47:58 +0100
Matthias Rabault wrote:
Hey Matthias,
> I see your point and I agree. I didn't think of that, so I'll have to
> think of another way to do that, which doesn't change the prototype.
> Thanks for the insight!
one way to handle this is to pull it in from vis.c via extern.
Attached is a patch which does just that.
Cheers
FRIGN
--
FRIGN
>From 3cc548817bf61c71c7744e43da3b0d083b95b8e4 Mon Sep 17 00:00:00 2001
From: FRIGN
Date: Sun, 4 Jan 2015 17:50:41 +0100
Subject: [PATCH] Set tabwidth and expandtab in config.def.h
Initial idea by Matthias Rabault
---
config.def.h | 3 +++
editor.c | 7 +--
vis.c| 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/config.def.h b/config.def.h
index cfd1771..87f0f6b 100644
--- a/config.def.h
+++ b/config.def.h
@@ -12,6 +12,9 @@
{ { NONE(127) }, (func), { .name = (arg) } }, \
{ { CONTROL('B') }, (func), { .name = (arg) } }
+#define TABWIDTH 8
+#define EXPANDTAB false
+
/* a mode contains a set of key bindings which are currently valid.
*
* each mode can specify one parent mode which is consultated if a given key
diff --git a/editor.c b/editor.c
index ef59242..38256df 100644
--- a/editor.c
+++ b/editor.c
@@ -17,6 +17,9 @@
# define MAX_COLOR_PAIRS COLOR_PAIRS
#endif
+extern int tabwidth;
+extern int expandtab;
+
static EditorWin *editor_window_new_text(Editor *ed, Text *text);
static void editor_window_free(Editor *ed, EditorWin *win);
static void editor_windows_invalidate(Editor *ed, size_t start, size_t end);
@@ -441,8 +444,8 @@ Editor *editor_new(int width, int height) {
goto err;
ed->width = width;
ed->height = height;
- ed->tabwidth = 8;
- ed->expandtab = false;
+ ed->tabwidth = tabwidth;
+ ed->expandtab = expandtab;
ed->windows_arrange = windows_arrange_horizontal;
return ed;
err:
diff --git a/vis.c b/vis.c
index cb401d9..c60db6b 100644
--- a/vis.c
+++ b/vis.c
@@ -526,6 +526,9 @@ static void switchmode_to(Mode *new_mode);
#include "config.h"
+int tabwidth = TABWIDTH;
+int expandtab = EXPANDTAB;
+
static Key getkey(void);
static void keypress(Key *key);
static void action_do(Action *a);
--
1.8.5.5
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
Thanks for the patch, I'll check it out this evening (can't yet, I'm using my phone). What I was thinking of was adding code in main() that alters the Editor structure according to config.def.h defines, just before calling the main loop. I'm trying that tonight, but what do you think of that ?
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
On Sun, Jan 04, 2015 at 06:12:00PM +0100, Matthias Rabault wrote: > Thanks for the patch, I'll check it out this evening (can't yet, I'm > using my phone). What I was thinking of was adding code in main() that > alters the Editor structure according to config.def.h defines, just > before calling the main loop. When looking at the main function you can see that the editor's statusbar field is being set using the "config"-pointer and a corresponding function called editor_statusbar_set. If you want to follow that pattern you can add two setter functions for tabwidth and expandtab and set the fields that way (either using the Config in config or a "#define"d value). I wonder though if it wouldn't be cleaner to just pass a pointer to the Config struct to the editor_new function and dealing with the field value initializations there.
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
I like your idea of passing a pointer to the config struct, that's cleaner and if new options are created, we only add them to the config structure without adding new arguments to editor_new(). Silvan Jegen a écrit : >On Sun, Jan 04, 2015 at 06:12:00PM +0100, Matthias Rabault wrote: >> Thanks for the patch, I'll check it out this evening (can't yet, I'm >> using my phone). What I was thinking of was adding code in main() that >> alters the Editor structure according to config.def.h defines, just >> before calling the main loop. > >When looking at the main function you can see that the editor's statusbar >field is being set using the "config"-pointer and a corresponding function >called editor_statusbar_set. > >If you want to follow that pattern you can add two setter functions for >tabwidth and expandtab and set the fields that way (either using the >Config in config or a "#define"d value). > >I wonder though if it wouldn't be cleaner to just pass a pointer to the >Config struct to the editor_new function and dealing with the field >value initializations there. > >
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
On Sun, Jan 04, 2015 at 06:22:00PM +0100, Silvan Jegen wrote:
> On Sun, Jan 04, 2015 at 06:12:00PM +0100, Matthias Rabault wrote:
> > Thanks for the patch, I'll check it out this evening (can't yet, I'm
> > using my phone). What I was thinking of was adding code in main() that
> > alters the Editor structure according to config.def.h defines, just
> > before calling the main loop.
>
> When looking at the main function you can see that the editor's statusbar
> field is being set using the "config"-pointer and a corresponding function
> called editor_statusbar_set.
>
> If you want to follow that pattern you can add two setter functions for
> tabwidth and expandtab and set the fields that way (either using the
> Config in config or a "#define"d value).
>
> I wonder though if it wouldn't be cleaner to just pass a pointer to the
> Config struct to the editor_new function and dealing with the field
> value initializations there.
I agree, adding individual options to editor_new is wrong. Somebody also
sent me a patch which makes the colors used for the line numbers configurable.
He introduced
editor_uicolors_set(Editor *ed, UIColors*)
where the UIColors struct would then be passed on to
Win *window_new(Text*, UIColors*)
while this passing around of global configuration data is somewhat
annoying I would like to keep {editor,window}.[ch] independent from
the editor frontend implementing the specific vis/nano/sam/whatever
interface. It should thus not directly refer to global variables.
--
Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] [vis] [PATCH] Set tabwidth and expandtab in config.def.h
On Sun, Jan 04, 2015 at 06:52:00PM +0100, Marc André Tanner wrote:
> On Sun, Jan 04, 2015 at 06:22:00PM +0100, Silvan Jegen wrote:
> > On Sun, Jan 04, 2015 at 06:12:00PM +0100, Matthias Rabault wrote:
> > > Thanks for the patch, I'll check it out this evening (can't yet, I'm
> > > using my phone). What I was thinking of was adding code in main() that
> > > alters the Editor structure according to config.def.h defines, just
> > > before calling the main loop.
> >
> > When looking at the main function you can see that the editor's statusbar
> > field is being set using the "config"-pointer and a corresponding function
> > called editor_statusbar_set.
> >
> > If you want to follow that pattern you can add two setter functions for
> > tabwidth and expandtab and set the fields that way (either using the
> > Config in config or a "#define"d value).
> >
> > I wonder though if it wouldn't be cleaner to just pass a pointer to the
> > Config struct to the editor_new function and dealing with the field
> > value initializations there.
>
> I agree, adding individual options to editor_new is wrong.
I tried another way, without adding options to editor_new. The idea was
editing the fields in Editor in the main() function. The patch is
attached. What do you think of it ?
Cheers,
Matthias
>From 2201279c011e409ac573b92728c74c959e6823d1 Mon Sep 17 00:00:00 2001
From: Matthias Rabault
Date: Sun, 4 Jan 2015 22:11:37 +0100
Subject: [PATCH] Set tabwidth and expandtab in config.def.h
---
config.def.h | 3 +++
vis.c| 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/config.def.h b/config.def.h
index aac28a8..70c1708 100644
--- a/config.def.h
+++ b/config.def.h
@@ -12,6 +12,9 @@
{ { NONE(127) }, (func), { .name = (arg) } }, \
{ { CONTROL('B') }, (func), { .name = (arg) } }
+#define TABWIDTH 8
+#define EXPANDTAB false
+
/* a mode contains a set of key bindings which are currently valid.
*
* each mode can specify one parent mode which is consultated if a given key
diff --git a/vis.c b/vis.c
index 7ccfa22..2be7b67 100644
--- a/vis.c
+++ b/vis.c
@@ -1891,7 +1891,9 @@ int main(int argc, char *argv[]) {
if (!editor_syntax_load(vis, syntaxes, colors))
die("Could not load syntax highlighting definitions\n");
editor_statusbar_set(vis, config->statusbar);
-
+ vis->tabwidth = TABWIDTH;
+ vis->expandtab = EXPANDTAB;
+
char *cmd = NULL;
for (int i = 1; i < argc; i++) {
if (argv[i][0] == '-') {
--
2.2.1
Re: [dev] [surf] tabs and clipboard
Hi, * Markus Teich 2015-01-04 13:03 > think). Since I also mostly use mono/fullscreen mode of dwm, opening single > Windows with no tabbing capability seems rather useless (more windows in the > view, more time spent finding the right one). how is searching in tabbed windows different from (better than) searching in monocle windows, could you please elaborate? thanks! --s
Re: [dev] [surf] tabs and clipboard
sta...@cs.tu-berlin.de said: > how is searching in tabbed windows different from (better than) > searching in monocle windows, could you please elaborate? In tabbed you see titles of all tabs, in monocle view - only the title of the current window. -- Dmitrij D. Czarkoff
