Giter Site home page Giter Site logo

bric's Introduction

Build Status

Waffle.io - Columns and their card count

Join our Matrix chat room!

bric

bric is a text editor based on kilo.

bric does not depend on any library (not even curses). It uses fairly standard VT100 (and similar terminals) escape sequences to write and read to and from the terminal.

A blog post by Casey, bric's first maintainer

Casey's blog post

Screencast of bric on macOS:

View Screencast

Getting the code

The code on the master branch is more likely to be unstable. See the Releases section for downloads that have been more thoroughly tested.

The links to the git repo or source archives can be found at https://github.com/shnupta/bric

Building and Installation:

From the top level of the source directory, run:

mkdir build
cd build
../configure (use `../configure --help` to set extra options)

By default, make install will install all the files in /usr/local/bin, /usr/local/lib etc. You can specify an installation prefix other than /usr/local using ../configure --prefix, for instance --prefix=$HOME or --prefix=$PWD/install_test.

make (Before install, the resulting `bric` binary will be located in src/)

If you have write privileges to prefix:

make install (otherwise, use `sudo make install`)

Note: You will never need root privileges to make bric, and it's good practice only to use super-user privileges when absolutely required.

Those instructions will be adequate for most users, but more details can be found in the INSTALL document.

Removing files:

make clean (or remove the build directory you created)
make distclean

Uninstalling

make uninstall (must be run before `make distclean`)

Usage:

If you have performed a make install then just bric <filename>. It can be a new or existing filename.

Currently bric only supports a few vim commands (with similar names) but plans are in place to implement more to make editing much easier and more efficient.

Config file: bric is customizable from a configuration file - ~/.bricrc

Here is an example config file:

set linenumbers true
set indent true

set hl_comment_colour 33
set hl_mlcomment_colour 33
set hl_keyword_cond_colour 36
set hl_keyword_type_colour 32
set hl_keyword_pp_colour 34
set hl_keyword_return_colour 35
set hl_keyword_adapter_colour 94
set hl_keyword_loop_colour 36
set hl_string_colour 31
set hl_number_colour 34
set hl_match_colour 101
set hl_background_colour 49
set hl_default_colour 37

set tab_length 8

Note: Not all options have to be set. The ones shown above are the colours (however indent maintaining and linenumbers are not)

Translating

If you are interested in translating bric, please see the TRANSLATE document.

Contribution:

I'm completely open to anyone forking and helping build features of the editor so go ahead and make a PR!

Please review the CONTRIBUTING guidelines.

The basic workflow as of November 2017 is:

  • Development and pull requests are made on the master branch.
  • These PRs will be reviewed and if accepted merged into the master branch.

Bugs and feedback:

To submit any bugs or give feedback please add an issue on this repo or join the bric chat room.

bric's People

Contributors

abhishek-kuvalekar avatar andy5995 avatar anfly0 avatar beethoven2138 avatar bleepcord avatar brendanbeerman avatar cloudstrif avatar doztrock avatar grikukan avatar jclopezdev avatar lukasho avatar martijndeb avatar midzer avatar mkiwi avatar mohamessi avatar nanopish avatar onlurking avatar partytime avatar pushb avatar rafaelcn avatar romainstasyszyn avatar rrreeezzz avatar shnupta avatar tacklebox avatar thecynosure avatar willdott avatar yashjakhotiya avatar zvonimirr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bric's Issues

Segfaults when newline at start

On Ubuntu 16.04 I got a segfault when I open a new file and press newline.

It seems to come from a uninitialized string sent to strlen line 653 in editor_insert_newline, created in get_indent_prefix.

Correct Makefile

The Makefile is a bit of a hack at the moment.

We should properly organise the list of dependent source files and also use the correct install command.

Fix tab length

When setting tab_length in the config file, and then pressing tab inside the editor it doesn't move the correct amount of spaces. E.g. if I set it to 4 in the config, it moves 3 spaces.

I've tested on Manjaro Linux, would anybody be able to confirm this on other OSs?

segfault if 'tags' file is wrong format

If the tags file is incorrectly formatted, bric will segfault when using the tagstack function.

To generate the correct tags file, the user must use Exuberant Ctags.

On Debian, the package exuberant-tags can be installed.

See this for more info.
https://stackoverflow.com/questions/2968542/the-ctags-command-doesnt-recurse-saying-it-is-not-a-regular-file

Some debugging will needed to be done to find out what's specifically causing the segfault, and some type of check to see if the file is a proper tags file.

code in support to use SYSCONFDIR

SYSCONFDIR can be passed to bric during compiling. it defaults to /usr/local/etc and can be changed during compile-time by using a ../configure option.

It's coded in as a define directive at the time of build, see

DEFS = -DLOCALEDIR=\"$(localedir)\" -DSYSCONFDIR=\"$(sysconfdir)\" @DEFS@

Bric should look for .bricrc (see #145) first in the user's home directory, and if not found, look in SYSCONFDIR for bricrc (no dot preceding the filename).

Config File

As seen below the colours are set in the editor_syntax_to_colour function in the syntax.h file. It would be good if the editor had default colours at the beginning but could read a config file (e.g. ~/.bricrc ) which contained a way of grabbing the user's preffered colours.

// map thee syntax highlight types to terminal colours
int editor_syntax_to_colour(int highlight)
{
        switch(highlight) {
                case HL_COMMENT:
                case HL_MLCOMMENT: return 33; // yellow
                case HL_KEYWORD_COND: return 36; // cyan
                case HL_KEYWORD_TYPE: return 32; // green
               case HL_KEYWORD_PP: return 34; // blue
               case HL_KEYWORD_RETURN: return 35; //magenta
               case HL_KEYWORD_ADAPTER: return 94; //grey
               case HL_KEYWORD_LOOP: return 36; //cyan
                case HL_STRING: return 31; // red
                case HL_NUMBER: return 34; // red
                case HL_MATCH: return 101; // background light red
               case HL_BACKGROUND_DEFAULT: return 49;              
               default: return 37; // white
        }
}

Also implement the newly added line numbers -l argument, but have option to turn on and off in config file.

Fix Ruby and HTML comment delimiters

Both the Ruby and HTML multiline comment symbols are larger than the char array that is inside the editor_syntax struct. All that needs doing is change the size of the array to be large enough to contain the symbols.

The Road Ahead

Hi guys,

The project has recently had a fair bit of growth (far more than I ever expected) and so I thought it would be a good idea to address some things to help everyone with development on the project.

I haven't really done much with bric for some time now having started college this year and been pretty busy with life in general, but it's great to see so many people getting involved (and kind of makes my life easier). All the new features and improvements that are being put forward are all extremely good and are really helping the editor progress.

However, as you'll probably know - if you have worked on the editor (on the vim-change branch) - the main code is quite a mess. We've started to separate some code into features but the main bric.c file is very cluttered and unorganised.

It would be great if the main focus over the next period of development could be on organising the code into separate files and components in order to make the editor easier and more friendly to work on.

So what would really help is if this thread could be full of comments and suggestions as to how we should refactor the editor into components and sub-components (e.g. core, movement etc.). I'd love for as many people to get involved and share their ideas as this should speed up the process.

The aim being that after the code has been organised and the editor is all working. We should be able to write a small amount of basic documentation on usage of the editor and also what the sub-components do so it is easier for new developers to get started.

Once this has happened we will use the master branch for stable code and then a beta and also development branch for new features and testing to be done.

Sorry for such a long message but I hope this will get a conversation going and help the progression of the editor before it becomes too much of a mess.

Thanks,
Casey

add default config file

A sample config file is shown on the README. This should be added to the distribution as .bricrc

Find and replace

Add a Ctrl-R to use find and replace. Look at the existing editor_find function and use that as the basis for the new replace feature.

Problem with some commentaries delimiter

In fact, the code is think for commentary token // and /* */ but for Python there is # and "" """ and for Ruby there is # and =begin =end. I tested the commentary highlighting with Python and Ruby monoline and multiline but no one work. I am working on it to try to be more general about commentary token gestion.

Test new undo function

Hi there everyone,

If possible could we get some people to test this new PR #90 on @DreamTheater2016 's development branch and comment your results back here please.

Many thanks! :)

Organise Code

Make sure all current code sticks to one code style (this code styling will be documented).

Add more commenting to parts of the code which are slightly harder to grasp quickly.

Overall, just make the code easier to read and understand before continuing with the refactor.

Refactor code

As suggested by @grikukan , the code base and features are becoming larger now so before the task is too large - refactor the code base into base, features and modules.

Segmentation Fault while deleting long line.

The bric executable crashes with segmentation fault (code dumped) if user keeps on pressing backspace on long texts.

Steps to reproduce:

  • open a new file in bric editor and copy the content of this attached file loremIpsum.txt in that file opened using bric, if possible split the content in multiple lines.
  • Start to delete from the very last character by pressing backspace after some time the editor shows garbage and after some time crashes with segmentation fault.

screenshot from 2017-12-28 22-21-50

Add more keyword possibilities

At the moment there are only two keyword varients: those that are normal strings e.g. "switch" and those with a trailing pipe e.g. "int|".

More options are needed to separate the colours out more into groups like conditionals, types, functions etc.

Look at modules/syntax/syntax.h and the editor_syntax_to_colour function in bric.c to see how colours work. And then also the editor_select_syntax_highlight function in bric.c.

These syntax functions may be separated into their own source file at a later date.

We need a different colour for these keywords:

  • types (int, float, string, char, void, true, false...)
  • preprocessor keywords (#define etc.)
  • conditions (if, else, switch, case...)
  • strings
  • numbers
  • return
  • const, static etc..
  • loops

Performance issue

When editing large files (> 100mb) some operations can be really slow. Probably it can be fixed by storing rows and texts in rows in linked lists instead of arrays.

Undo function

Allow the previous few operations to be undone by the user.

Current undo needs:

  • Should bind to ctrl-z in insert mode
  • Should bind to ctrl-z and u in normal mode
  • Should be able to undo at least the last 25 operations.
  • Ctrl-r for redo. (undo the last undo)

Write documentation

Write a brief documentation file on how the editor works (from 0.0.2) and the basics of some of the key components of the editor.

Yank & Paste

We need a shortcut that allows us to copy the whole line (yank the line) and then another shortcut than pastes in the line at the current cursor position.

Some useful functions might be editor_insert_newline and editor_insert_char

Makefile.am needs noinst_HEADERS section

In order for make distcheck to work, the header files need to be specified in

src/handling.c

Therefore, this section needs to be added under the bric_SOURCES section

noinst_HEADERS =

It should contain the list of header files this program uses when it compiles.

Write contributing guide

The guide should provide a first base for all new contributors (the basics such as finding an issue and making a PR) and also contain guidelines on style and code preference. (Unless we decide to use a code beautifier).

minor string change suggestions

I wanted to create a ticket for the suggestion @sexybiggetje posted in #121

Please find the attached zip file. Github doesn't allow the po file directly.
I also shared some common language notes. Doing it this way because I don't have commit acces to this branch.

#: src/bric.c:1878 src/bric.c:1883 src/bric.c:1887 src/bric.c:1893
#: src/bric.c:1911 src/bric.c:1915
msgid “Insert mode. ”
msgstr “Invoeg modus. ”

It has a space at the end.
Normal mode later in the file doesnt

#. TRANSLATORS: “Bric” is the program name and should not be translated
#: src/bric.c:918
#, c-format
msgid “Bric editor -- version %s[0K\r\n”
msgstr “Bric editor -- versie %s[0K\r\n”

Ends with \r\n

#: src/bric.c:2203
#, c-format
msgid “The file has been locked, try to remove the locker!\n”
msgstr “Het bestand is vergrendeld, probeer de locker te verwijderen!\n”

Ends with \n
All should be \r\n or \n methinks

#: src/bric.c:1492
#, c-format
msgid “There are unsaved changes, quit? (y or n) %s”
msgstr “Er zijn onopgeslagen wijzigingen, afsluiten? (y of n) %s”

should be j of n, (ja of nee) in dutch, but I kept y/n because keymap should change then as well

#. TRANSLATORS: “bric” is the program name, do not translate
#: src/bric.c:704
#, c-format
msgid “bric: invalid option -- ‘%c’\n”
msgstr “bric: invalide optie -- ‘%c’\n”

My response.. these suggestions all look reasonable, but I have some questions or comments:

the \r\n note should apply here as well

@shnupta is \r needed? I get warning when running make update-po about the use of \r but I don't think it's anything to important and can probably be suppressed (if necessary) by changing the CHARSET at the top of po files.

should be j of n, (ja of nee) in dutch, but I kept y/n because keymap should change then as well

The program can only accept a y or n as input in that case, so I think you're right to leave it as is. Maybe there are some alternatives that can be used in the future. @sexybiggetje you must have come across a lot of cases like that when translating rmw, ja? xD

lines modified should be modified to support extra plural forms

bric/src/bric.c

Line 1006 in 8f79d01

int len = snprintf(status, sizeof(status), "%.50s =- %d lines %s", Editor.filename, Editor.num_of_rows, Editor.dirty ? "(modified)" : "");

I suggest 2 things happen to this string.

  1. Use ngettext() to support plural forms
  2. combine the string (so "lines" and "modified" will be on a single line in a po file)

Right now, essentially the string is "combined", but for it to appear as a single translatable line in a po file, in the source code, the string must not be broken apart.

It will require adding a few extra lines of code, but it's really the preferred method.

For more info, see
https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html#Plural-forms

Quitting in insert mode does not remove lock

When quitting via ctrl-Q in insert mode, the file lock is not removed. I'm not sure if that's intended, but if not I would be glad to fix it to be consistent with quitting in normal mode.

Error with absolute path

Hello!

Today I was trying to implement a little feature and I've realized something.

I've "checkouted" my repository version to the last commit, after:

make clean all
sudo make install

I've installed bric in my computer, after I've tried to edit a file in an absolute path (e.g.):

bric /home/doztrock/Desktop/file.txt

BUT!

At the footer, there's a message:

/home =- 0 lines 1/0
Normal mode.

I've written some text inside the editor, and, I've gotten the following error:

Cannot save! I/O error: Is a directory

I think there's a problem with the absolutes path, anyway, I'll try to find and correct the issue if possible, ASAP.

Regards.

P.S. Please confirm you've gotten the same error, maybe my computer is asking for a replacement. :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.