Re: [dev] [edit] Introducing edit, a simple text editor

[Daniel Littlewood]

Hi Arthur, I tried to build your project, but it failed for me:

termbox2.h:2209:22: error: storage size of ‘sa’ isn’t known
termbox2.h:2345:46: error: ‘struct sigaction’ has no member named ‘sa_handler’
termbox2.h:2345:44: error: invalid use of undefined type ‘struct sigaction’

All the best,
Dan

On Wed, Sep 27, 2023 at 1:15 PM Arthur Jacquin  wrote:
>
> Hello suckless developers,
>
> This is my first time here, I hope I'm doing everything correctly :)
>
> There is a bit of a story leading to this post. About a year ago, I
> discovered the kakoune text editor. At that time I was a pretty happy
> vim user, but kakoune arguments for its reversed grammar[0] resonated
> with me and soon made me want a vim replacement.
>
> Already aware of and enthusiastic about the suckless philosophy, I
> started by exploring the text editors referenced there[1]. I was
> looking for the combination of a simple yet powerful editing model and
> a truly suckless development style. As none satisfied me, I decided to
> write my own.
>
> The result is edit[2] (yeah, quite creative on the name).
>
> It uses a kakoune-inspired selection-centric, selection-then-action
> model. This makes multi-cursor or column/block editing natural,
> without getting in the way for simple editing.
>
> In a typical suckless fashion, edit is written in C99 with no external
> dependencies, and is very easy to configure, hack on and extend. The
> terminal drawing stuff is done by termbox2.h, a single-header library
> discovered on [1].
>
> In about 2.2K lines (plus 2.7K lines for termbox2.h), edit packs quite
> a few features, such as syntax highlighting, autocompletion, a line
> clipboard, and a search and replace engine supporting regular
> expressions and subpatterns and fields reuse.
>
> By now, it's fairly stable. No major change is expected, and I'm
> gradually polishing it towards version 1.0. If you're interested in
> taking the time to discover edit, the online manual page[3] might be a
> good starting point. I'm looking forward some feedback, so feel free
> to share your comments ;)
>
> Happy hacking,
>
> Arthur
>
> [0]: https://kakoune.org/why-kakoune/why-kakoune.html
> [1]: https://suckless.org/rocks/
> [2]: https://jacquin.xyz/edit
> [3]: https://jacquin.xyz/edit.1
>
>
>
>
>

Re: [dev] Minimalist software. Should I care?

[Daniel Littlewood]

I tried to respond to the original question the other day but
failed to set up text mode correctly. ugh.

> What would be the point of using minimalist software if
> bloated and excessively complex programs completely satisfy
> all my needs?

I think there are a couple of reasons. Not all of them apply to all people, or
all programs.

Composability. If you write lots of small programs, then your complex
functionality has to come from combining them together. For example, Firefox
has tabs, and xterm has tabs. These functions are implemented in different ways
in the different programs, and when I wake up one day and decide I want a
tabbed PDF reader, or a tabbed file browser, I can't have it. If all your needs
are satisfied then this isn't important, but sometimes the flexibility makes me
aware of needs I didn't already know about.

Low maintenance burden. The bigger the project, the more extraneous concerns
like testing, issue tracking, packaging and monetisation burden the actual
functionality of the software. You can see this with projects like chromium,
where it takes 100 hours to compile on a typical PC and the software is so
buggy that they refuse to package it for Ubuntu (and provide only a snap
package). Free software is hard to monetise, and if every single "app" needs a
million dollars a year to maintain its DevOps pipeline, you aren't going to get
many apps.

Effective freedom. You mention TeXstudio as a piece of software you use and
rely on. I have used TeXstudio before and hated it. The two features I remember
really getting in my way were the text editor and the rendering of a compiled
document. For the text editor: It had all these weird keyboard shortcuts that
got in my way. It would complete brackets when I didn't want, and it lacked a
lot of features that I like in my usual text editor. Similarly, the document
would not live recompile when I saved changes (which is a feature I happened to
want).

So - why can't I have these features? If I go away and find a text editor I
like (I have) and I write a script that recompiles the document (I have) and I
make it watch the filesystem for writes (I have) why can't I use the rest of
the things in TeXstudio that I *do* like? Well, it's because it would be too
hard to integrate them in. TeXstudio would have to add in configuration options
for a text editor, and for a pdf viewer, and it's too complicated to make that
work. Ironically, late in the project, it takes *more* development work to make
the program do *less* work.

My experience has been that large software projects tend to absorb
functionality until they try to be the only program you can use. People like to
pretend this isn't an issue with Free Software, but just look at firefox. Why
are there accounts? Why does it include a password manager? Why does it have
its own PDF reader? There are basically two outcomes: You like the feature, and
you'd like it elsewhere, or you don't like the feature, and you want to remove
it. Both are harder the bigger the project.

Finally, it helps me understand my computer. I like to know what's running, and
how it works. If something breaks, I want to be able to fix it. I can
only do that if
I understand what it's doing. And nobody understands how bloated software
works.

Dan

Re: [dev] bump copyright years?

[Daniel Littlewood]

I would also be in favour of removing the dates. For actively developed
software, copyright expiry is a sort of fantasy concept. By the time author 1
has been dead for 70 years, the software has probably had thousands of authors
who remain alive. I only use dates like that to get a rough idea of who was
working on a project when, in which case (as you say) they should be kept
updated. But I don't think it serves any real utility.

Best wishes,
Dan

On Wed, Feb 8, 2023 at 10:20 AM Tom Schwindl  wrote:
>
> Hi all,
>
> I've recently (well, a few days/weeks ago) read quite a few discussions on
> a wide variety of mailing lists about whether to remove the range of years
> from the copyright notices or keep them. Since a few of our LICENSE files are
> out of date too, I wonder if there is a consensus on what to do.
> Should we update them and do the usual "bump the year" dance?
> Or should we completely drop them and stop worrying.
> I do not have strong opinions on this, but I think if the years are stated,
> they should at least be correct.
>
> I like to link to the musl discussion here since they go into more depth on 
> the
> topic. Unfortunately, I think they didn't come to a conclusion:
>
> 
>
> The reason why I bring this up is that I think it's irritating, or at least
> inconsistent, if a project is actively developed but the LICENSE file states
> something like "(c) 2010-2015".
>
> --
> Best Regards,
> Tom Schwindl
>

Re: [dev] Is there a text editor following the UNIX philosophy?

[Daniel Littlewood]

My impression so far with acme is that it fills the "IDE" gap much
more than the "text editor" gap. I watched a screencast by Russ Cox
(https://www.youtube.com/watch?v=dP1xVpMPn8M) and the appealing
features were mostly around co-ordination of windows rather than the
contents of the windows themselves. Being able to right-click a file
reference (to redirect directly to a failing test, for example) is
handy.

It's kind of funny that they insist on using a GUI, but all of the
windows are designed to render text and nothing else. I wonder whether
a similarly designed program, with mouse chording replaced by
customisable buttons?, and the acme windows replaced by terminals,
would provide many of the gains with less weirdness.

On Sat, Feb 12, 2022 at 2:30 PM Ethan Marshall
 wrote:
>
> > Acme looks extremely neat. Mouse
> > chording is a strange concept (which doesn't play nicely with my
> > laptop mouse)
>
> This is something that I fundamentally disagree with the designers of
> acme on, actually. I think that mouse "chording" or mouse-based
> shortcuts of any kind are slow and wasteful of precious time.
>
> When entering text, you keep your hands on the keyboard. I see no reason
> why we should introduce yet another input device for simply editing or
> transforming the text. This is why so many programs naturally gravitate
> toward cursor-addressed, textual editing. vi is designed to keep your
> fingers on the home row when moving the cursor, so touch typing is meant
> to be easier. Not only is this a stroke of genius (something that I feel
> Emacs never succeeded in), it also has wide, practical implications on
> your editing of text. Why should I reach for a mouse to cut the previous
> section of text when I can keep using the current input device? Rather
> than moving my hands over an inch, instead I can not move them at all
> and get the same result, the only requirement being that I press escape
> first.
>
> The usual counter-argument for this is that the keyboard is an imperfect
> device for this situation, as it was not designed for anything but
> inputting characters. So - in theory - the time saved from using a
> device meant for this purpose should be better. However, practice again
> teaches us that this is not the case. Mice are the bane of most users'
> lives when they are forced to use them for editing text. You have to
> take your hand off the keyboard, move them to some arbitrary location,
> correctly manoeuvre the mouse, move back to the initial position and
> finally edit your text. After all this, you may have to repeat the
> process to navigate to the end of the text.
>
> Even if the mouse were, in fact, the perfect time-saver that we are
> told, it is not designed for such shortcuts and chording. The mouse has
> three buttons. These were intended with three very clear purposes. The
> keyboard usually has 104+ keys on it for usage in key shortcuts. The
> mouse? Three. If we assume chording, a theoretical maximum of nine
> shortcuts. However, to access them, you have to memorize a nonsensical
> pattern of M1-M2 (Emacs style). Instead, to delete text in my silly,
> inefficient visual editor, I just press d on my keyboard.
>
> This may just be me being a perfectionist who likes to edit back what he
> has just written, or it may just be something that I feel personally
> about mice, but I cannot understand why you would build an editor for
> programmers which does not use keyboard bindings.
>
> I have tried acme and sam. Both have their benefits, and I like the some
> of their ideas. I tried acme for equal to or greater than the amount of
> time which I spent learning vi(m) - and I just cannot like it.
>
> Ethan
>

Re: [dev] Is there a text editor following the UNIX philosophy?

[Daniel Littlewood]

Thanks for the suggestions everyone. Acme looks extremely neat. Mouse
chording is a strange concept (which doesn't play nicely with my
laptop mouse), but the idea of building an IDE around customised short
shell commands is really appealing. As for text editing specifically,
the idea of piping a buffer through sed rather than a custom
implemented search-and-replace utility is really interesting. Ditto
spell checking. Compared with a vim-like editor, navigating through a
buffer seems much more painful - but perhaps I haven't found the right
strategy yet. The lack of syntax highlighting, and the ugly GUI (which
can't be run in console mode) are unfortunate.

About syntax highlighting in particular, my naive suggestion would be
to constantly pipe the input file/buffer through a program which
decorates it with appropriate ANSI colour codes, which could then be
interpreted by your preferred reader. This sounds absurd in terms of
performance, but I don't understand how implemented syntax
highlighters do anything different - presumably new tokens can make
pretty much arbitrary changes to the underlying syntax tree, and yet
vim (for example) will re-highlight an entire file quite happily.

Regarding "can this be done" - I can't be sure. But for "is this even
useful" - surely yes? I happen to have syntax highlighting in my text
editor. Why not in my shell/terminal/pager? Why should they implement
them differently? I happen to have tab completion in bash, and with a
vim plugin. Why are they unconnected?

For what it's worth (I know this is not particularly fashionable) -
I'm much more interested in separating separable features than
implementing the same feature set in less code. You may be right that
these are not really separable features, but if they *are* separable,
then it's not persuasive to me that they can be implemented in a small
number of lines.

All the best,
Dan

[dev] Is there a text editor following the UNIX philosophy?

[Daniel Littlewood]

Hi all,

There was a recent chat about cat -v & single-purpose programs which
has been rattling around my head for the last few weeks. There are
*many* bloated code editors (atom, vscode, etc.), but most people
usually present either emacs or vim as an alternative. I can't see
these as any less bloated - there are very old jokes about emacs being
a great OS which is just missing a text editor. And vim implements a
lot of features that feel like they could (hence should) be provided
by other utilities. Examples include syntax highlighting, text
completion, search and replace, pane management (!), and others.

It seems to me like the obvious alternative workflow would be, rather
than to have a single monolithic program for the general job of
"editing text" (which is really lots of jobs pretending to be one),
one might have a program for syntax highlighting, a program for
completion, a facility for dispatching text to shell commands, and so
on. On the more extreme end one could even imagine separating the jobs
of navigating through a buffer (i.e. a pager) from the editing of
text. Obviously that's not a complete idea by itself, or I wouldn't be
asking for suggestions.

I found kakoune, which seems essentially like a vim clone with better
shell integration. From the other end, there is always ed.
Unfortunately I don't have much experience with it, and it's not often
discussed, so I can't tell whether it could do the "integration" step.

I wonder whether there are any text-editing (particularly
code-editing) workflows people have had success with which combine
many small programs, rather than using a single monolith.

Re: [dev] Sxmo presentation at AlpineConf (Sat May 15, 14:30 UTC)

[Daniel Littlewood]

It was earlier today, the recording on youtube is here:
https://www.youtube.com/watch?v=VOW6APA4sTY&ab_channel=proycon

Really interesting presentation! I've been wondering for a long time
whether a little creativity could make terminal apps more functional
on mobile. If I can figure out how to make a reliable backup of my
android phone, I'll be trying it later tonight.

all the best,
Dan

On Sat, May 15, 2021 at 7:02 PM Hritik Vijay  wrote:
>
> On Fri, May 14, 2021 at 03:59:47PM +0200, Maarten van Gompel wrote:
> > I just wanted to drop a little announcement that this weekend on
> > AlpineConf 2021, we will present Sxmo, the simple X mobile environment.
> Sounds really cool. Will surely attend. Let's see if it makes into
> suckless ;)
>
> Hrtk
>

[dev] [st] Patch/feature request - redraw terminal on resize

[Daniel Littlewood]

Hi all,

I have noticed a feature from tmux that I would like to have in vanilla st.
The behaviour is that when the screen resizes, the window is redrawn
to fit the new size.
In vanilla st, if I make the window smaller then output that was
previously drawn there is blank.
If I'm running a program like "man" in the terminal, then the lines
are broken in a strange place and I have to restart it to get them
correct.
This sounds like the perfect sort of thing for a patch, but I can't
see anything in the patches section of the FAQ about this idea.
Does anybody know if such a patch exists, or where to start
implementing it myself?
(I can include screenshots too if my description is not clear)

Thanks a lot,
Daniel