Seeking advice on writing a "line-based" major mode

Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

Hi all,

I'm going to start coding a major mode, a bit like dired or grep-mode or
org-agenda mode, in which the buffer will contain a bunch of lines, each
of them correspoding to some object (basically, I have a vector of these
"objects", and I want to display them in some way).

This raises two problems.

1. I want to be able to display these objects using some kind of
a "template" (not unlike org's "property table", or dired's format
etc.).  I'd like this "template" to be configurable using a user option
(with possibilities like "x characters for a name, then y characters for
description, etc. for other fields").

2. When the point is one one of these lines, I want various keybindings
to perform some actions on the object in question (like, again, in
Dired or org-agenda).

Is there anything in Emacs or its libraries which might help with these
tasks?  For instance, each "object" is identified by a name (it's the
"primary key", so to speak), but it need not be e.g. the first thing on
the line.  The displaying function could use text properties of the
particular lines so that Emacs knows which object to act upon when point
is in some place, but maybe there is a ready-made library for that?

And maybe there is even a more general library to establish
a correspondence between some vector/list of objects and a buffer whose
lines contain some textual representation of these objects, so that
I wouldn't have to code e.g. the displaying routine from scratch?

Of course I could code all that myself - it doesn't seem to be too much
work - but why reinvent the wheel?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> This raises two problems.
>
> 1. I want to be able to display these objects using
> some kind of a "template" (not unlike org's
> "property table", or dired's format etc.). I'd like
> this "template" to be configurable using a user
> option (with possibilities like "x characters for
> a name, then y characters for description, etc.
> for other fields").
>
> 2. When the point is one one of these lines, I want
> various keybindings to perform some actions on the
> object in question (like, again, in Dired or
> org-agenda).

Use the source, Luke!

If it is like Dired and org-agenda (?) then check out
that source.

It sounds like you can also benefit from checking out
the sources of `package-menu-mode',
`Buffer-menu-mode', and even the Gnus group and
summary modes if you are brave.

Dig in!

> Of course I could code all that myself - it doesn't
> seem to be too much work - but why reinvent
> the wheel?

Answer: because it is enjoyable, interesting, and
creative as you don't focus on understanding what
someone else did but instead on what you can do and
what you can learn how to do, thus getting exactly
what you want and nothing else - and besides, this
time a"round" you might stumble on something that will
revolutionize the entire pitch-black wheel industry!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> I'm going to start coding a major mode, a bit like
> dired or grep-mode or org-agenda mode, in which the
> buffer will contain a bunch of lines, each of them
> correspoding to some object (basically, I have
> a vector of these "objects", and I want to display
> them in some way).

By the way, "line-based" is confusing because it makes
you think about the line *editors* (e.g., ed).

But I understand what you mean so I suppose confusion
was kept at an acceptable level.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 00:23, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> This raises two problems.
>>
>> 1. I want to be able to display these objects using
>> some kind of a "template" (not unlike org's
>> "property table", or dired's format etc.). I'd like
>> this "template" to be configurable using a user
>> option (with possibilities like "x characters for
>> a name, then y characters for description, etc.
>> for other fields").
>>
>> 2. When the point is one one of these lines, I want
>> various keybindings to perform some actions on the
>> object in question (like, again, in Dired or
>> org-agenda).
>
> Use the source, Luke!

Yeah, sure.  That's a good idea in general, but it has one drawback:
there's only 24 hours per day.

> If it is like Dired and org-agenda (?) then check out
> that source.

I might be tempted to look at Dired.  I'm scared of org-agenda source
code.

> It sounds like you can also benefit from checking out
> the sources of `package-menu-mode',
> `Buffer-menu-mode', and even the Gnus group and
> summary modes if you are brave.

Well, maybe I am brave, but I'm not mad.  Nor do I want to become
mad. ;-P

> Dig in!
>
>> Of course I could code all that myself - it doesn't
>> seem to be too much work - but why reinvent
>> the wheel?
>
> Answer: because it is enjoyable, interesting, and
> creative as you don't focus on understanding what
> someone else did but instead on what you can do and
> what you can learn how to do, thus getting exactly
> what you want and nothing else - and besides, this
> time a"round" you might stumble on something that will
> revolutionize the entire pitch-black wheel industry!

Again: in general, yes.  OTOH, there are so many other enjoyable,
interesting, and creative activities out there, even if you use
ready-made solutions to /some/ of your problems...  And writing rather
simple and boring Elisp code is not really very high on my list.  (Not
that writing Elisp is simple or boring in general: just that coding this
particular thing seems to me a lot like reimplementing well-known
things, and reimplementing a "format"-like function, for instance, seems
to be not very enjoyable/interesting/creative...)

But I agree with your previous point, studying someone else's code is
a good thing to do.  That is precisely why I assigned a fixed amount of
my time every day to studying code written by others.  I studied most of
ox-latex.el, some portion of AUCTeX source, some parts of simple.el...
Now I'm in the midst of digging through some C.  And I have to admit
that I learn a lot from this experience: both what to do and what not to
do...

Still, I hope that there /might/ be a general enough solution to my
problem so that I don't have to do it from scratch.

Thanks anyway

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 00:28, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> I'm going to start coding a major mode, a bit like
>> dired or grep-mode or org-agenda mode, in which the
>> buffer will contain a bunch of lines, each of them
>> correspoding to some object (basically, I have
>> a vector of these "objects", and I want to display
>> them in some way).
>
> By the way, "line-based" is confusing because it makes
> you think about the line *editors* (e.g., ed).

What term would you propose for a library that establishes a one-to-one
relationship between some collection of objects and lines in some
buffer?

> But I understand what you mean so I suppose confusion
> was kept at an acceptable level.

I would hope so! ;-)

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Joost Kremers]

Marcin Borkowski wrote:
> And maybe there is even a more general library to establish
> a correspondence between some vector/list of objects and a buffer whose
> lines contain some textual representation of these objects, so that
> I wouldn't have to code e.g. the displaying routine from scratch?

I'm currently looking at tabulated-list-mode for something similar (or
not, depending on the details ;-) myself. It seems to have some of the
properties that you are looking for, although it's probably not a
perfect fit. Might still be worth a look, though:

(info "(elisp) Tabulated List Mode")

HTH


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> the buffer will contain a bunch of lines, each of them
> correspoding to some object (basically, I have a vector
> of these "objects", and I want to display them in some way).

Sounds like a candidate for `tabulated-list-mode'.  You can
use that to print lines that are composed of one or more
columns, and a header line that let you sort by any column
(if you want).

> 1. I want to be able to display these objects using some kind of
> a "template" (not unlike org's "property table", or dired's format
> etc.).  I'd like this "template" to be configurable using a user
> option (with possibilities like "x characters for a name, then y
> characters for description, etc. for other fields").

That sounds like exactly what `tabulated-list.el' lets you do.
See (buffer-local) variable `tabulated-list-format'.

> 2. When the point is one one of these lines, I want various
> keybindings to perform some actions on the object in question
> (like, again, in Dired or org-agenda).

By default, RET on an entry in the table (i.e., in a given row
and column) just sorts that column.  But you can bind it to do
anything you like.

You might take a look at my library apu.el, which uses t-l-mode
this way.  The info in each row of the table is info about a
given Unicode char.  When you hit RET anywhere in that row a
buffer pops up with more complete info about that char.  Various
keys perform other actions on the given char.
http://www.emacswiki.org/emacs/apu.el (I haven't yet put it on
MELPA.)

> Is there anything in Emacs or its libraries which might help with
> these tasks?  For instance, each "object" is identified by a name
> (it's the "primary key", so to speak), but it need not be e.g.
> the first thing on the line.

Same thing with t-l-mode.

> The displaying function could use text properties of the
> particular lines so that Emacs knows which object to act
> upon when point is in some place, but maybe there is a
> ready-made library for that?

You can use text properties that way with t-l-mode, but you
should not need to.

> And maybe there is even a more general library to establish
> a correspondence between some vector/list of objects and a buffer
> whose lines contain some textual representation of these objects,
> so that I wouldn't have to code e.g. the displaying routine from
> scratch?

Again, that description sounds just like t-l-mode.

> Of course I could code all that myself - it doesn't seem to be too
> much work - but why reinvent the wheel?

Right.

[BTW, I would recommend against looking to things like Dired as
examples for this kind of thing.  Dired is very complex and does
lots of things in special ways.  And its code has evolved
organically, so to speak. ;-)  It is not something simple like what
you describe.  Look instead to things like buff-menu.el (which now
uses t-l-mode) and `list-faces-display' and `list-colors-display'.

Re: Seeking advice on writing a "line-based" major mode

[Tom Tromey]

Marcin> I'm going to start coding a major mode, a bit like dired or grep-mode or
Marcin> org-agenda mode, in which the buffer will contain a bunch of lines, each
Marcin> of them correspoding to some object (basically, I have a vector of these
Marcin> "objects", and I want to display them in some way).

People have already mentioned tabulated-list-mode.

Another way to go is EWOC, also part of the Emacs core.
EWOC is used at least by vc-dir but also I think some other modes.

I would suggest using whichever one fits your needs best.

Tom

computer and wheel time (was: Re: Seeking advice on writing a "line-based" major mode)

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Yeah, sure. That's a good idea in general, but it has
> one drawback: there's only 24 hours per day. [...]
>
> Again: in general, yes. OTOH, there are so many
> other enjoyable, interesting, and creative
> activities out there, even if you use ready-made
> solutions to /some/ of your problems... And writing
> rather simple and boring Elisp code is not really
> very high on my list. (Not that writing Elisp is
> simple or boring in general: just that coding this
> particular thing seems to me a lot like
> reimplementing well-known things, and reimplementing
> a "format"-like function, for instance, seems to be
> not very enjoyable/interesting/creative...)

In general, I'd say using a computer isn't a good idea
if you are concerned with time. In particular, using
Emacs and even more so, configuring/extending it will
in effect disintegrate even the most sparse schedule!

It is a paradox: you think, if I can make my system
faster and more powerful for my purposes, I will be
more productive. While true, once you have achieved
that higher level of productiveness and power, you
realize there is so much more to do, and then you have
to reach *that* level as well, and then it just goes
on and on much like this sentence I'm currently typing
(or so it would seem).

Compare building a bicycle wheel with a nipples,
a rim, spokes, and a hub. Do it for one hour while
listening to an episode of "Survivor", that is
experienced as - yeah, about one hour!

But write an Elisp defun, a zsh function, and write
1-2 Usenet posts - and that seems like the blink of an
eye. Now check the time: a full hour has passed!

No, the best (only?) reason to do it is if you like to
do it. Then you should, for sure.

Remember, "this is not the time to argue about time.
We don't have the time!"

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: computer and wheel time

[Dan Espen]

Emanuel Berg <embe8573@student.uu.se> writes:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> Yeah, sure. That's a good idea in general, but it has
>> one drawback: there's only 24 hours per day. [...]
>>
>> Again: in general, yes. OTOH, there are so many
>> other enjoyable, interesting, and creative
>> activities out there, even if you use ready-made
>> solutions to /some/ of your problems... And writing
>> rather simple and boring Elisp code is not really
>> very high on my list. (Not that writing Elisp is
>> simple or boring in general: just that coding this
>> particular thing seems to me a lot like
>> reimplementing well-known things, and reimplementing
>> a "format"-like function, for instance, seems to be
>> not very enjoyable/interesting/creative...)
>
> In general, I'd say using a computer isn't a good idea
> if you are concerned with time. In particular, using
> Emacs and even more so, configuring/extending it will
> in effect disintegrate even the most sparse schedule!

Actually, you spend a little time customizing then
real work goes faster, more accurately.  It's
a win win.

The more you customize, the less time regular work
takes.

Just try to keep the ratio under control.

-- 
Dan Espen

Re: computer and wheel time

[Daniel Corbe]

Dan Espen <despen@verizon.net> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>
>> Marcin Borkowski <mbork@mbork.pl> writes:
>>
>>> Yeah, sure. That's a good idea in general, but it has
>>> one drawback: there's only 24 hours per day. [...]
>>>
>>> Again: in general, yes. OTOH, there are so many
>>> other enjoyable, interesting, and creative
>>> activities out there, even if you use ready-made
>>> solutions to /some/ of your problems... And writing
>>> rather simple and boring Elisp code is not really
>>> very high on my list. (Not that writing Elisp is
>>> simple or boring in general: just that coding this
>>> particular thing seems to me a lot like
>>> reimplementing well-known things, and reimplementing
>>> a "format"-like function, for instance, seems to be
>>> not very enjoyable/interesting/creative...)
>>
>> In general, I'd say using a computer isn't a good idea
>> if you are concerned with time. In particular, using
>> Emacs and even more so, configuring/extending it will
>> in effect disintegrate even the most sparse schedule!
>
> Actually, you spend a little time customizing then
> real work goes faster, more accurately.  It's
> a win win.
>
> The more you customize, the less time regular work
> takes.
>
> Just try to keep the ratio under control.

Eventually you begin to butt up against the law of diminishing returns.
Spending half an hour on something that's going to save you 10 minutes
every day is a net gain; however, you'll eventually run out of those
types of problems to solve.

Pretty soon you'll be spending half an hour on something that saves you
30 seconds here and there and that's likely to be a net loss.

Then again, emacs really *can* do some pretty cool things.

Re: computer and wheel time

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> Actually, you spend a little time customizing then
> real work goes faster, more accurately.
> It's a win win.
>
> The more you customize, the less time regular
> work takes.

That's true, but only if regular work sticks within
some frame.

Programming is a good example as tho many modes and
languages exist, it is basically about writing code
and dealing with files. You got that configured and
extended then speed kills.

But: if there are completely new things and new
technologies that can mess up your plans. An example
is RMAIL. I used that and spent much time dealing with
it in different ways to make it behave the way
I liked, and also compensating for its drawbacks.
Then I found Gnus which instantly solved all that and
I throw away RMAIL and all my work. But with Gnus, tho
not having the issues of RMAIL, it was just so much
more power and thus a lot more to tweak.
Similarly I did much on Irssi before I found ERC, and
I did much to bridge the gap between Emacs in a
Linux VT and X, just because I had Iceweasel in X.
Then I found Emacs-w3m and again while not having to
deal with the X issues that didn't stop the
config/extend need for Emacs-w3m. Even within systems
it is the same story: I did Usenet with Gnus and
aioe.org and did work on that, only until I found
Gmane which obsoleted much of my work.

But now I'm done. I think...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: computer and wheel time

[Emanuel Berg]

Daniel Corbe <corbe@corbe.net> writes:

> Eventually you begin to butt up against the law of
> diminishing returns. Spending half an hour on
> something that's going to save you 10 minutes every
> day is a net gain; however, you'll eventually run
> out of those types of problems to solve.
>
> Pretty soon you'll be spending half an hour on
> something that saves you 30 seconds here and there
> and that's likely to be a net loss.

That's exactly right! I didn't know there was a name
for it but it is something I've seen many times and
yes, in Emacs as well.

So the question is, why do you do the "loss" stuff?
Probably because your brain is trained to think like
that, because that has worked so well during the
"gain" period!

But equally true, people like Lisp. I wish there was
a way that creativity and enjoyment could be
positioned for everyone's gain.

The problem with big software projects is that the
programmer has not experienced that problem first hand
so is alienated from the domain day one and when there
is adversity he is much more likely to quit. It isn't
exactly writing two or three defuns about six lines
each, then try them and see they work and use them to
solve the issues that arose ten minutes ago, and see
them solved before your eyes. Especially to people who
write code all days those innocent six-liners must be
very refreshing indeed...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: computer and wheel time

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> Daniel Corbe <corbe@corbe.net> writes:
>
>> Eventually you begin to butt up against the law of
>> diminishing returns. Spending half an hour on
>> something that's going to save you 10 minutes every
>> day is a net gain; however, you'll eventually run
>> out of those types of problems to solve.
>> Pretty soon you'll be spending half an hour on
>> something that saves you 30 seconds here and there
>> and that's likely to be a net loss.
>
> That's exactly right! I didn't know there was a name
> for it but it is something I've seen many times and
> yes, in Emacs as well.
>
> So the question is, why do you do the "loss" stuff?
> Probably because your brain is trained to think like
> that, because that has worked so well during the
> "gain" period!

One more thing I forgot! It is not only about time, it
is also enjoyment, again. But here, I mean *using* it
(in the last post I meant *writing* it).

For example, I really, really dislike looking and
searching for things. Even iterating two or three
steps och opening a directory to see what's there!
I'd rather go 200 meters to fetch a pipe wrench if
I know exactly where it is, than look for it in a shed
full of tools right next to me. Even if getting it
from the shed is much faster (including search time),
the frustration of having to look and finding it in
a seemingly random way is so much worse than waking to
get it, which can be a good break even.

So the question is both: "Will this be faster?" and
"Will I be more happy using it this way?"

If you are happy and relaxed doing things you don't
waste as much energy. You will be more productive and
have a more happy life tho as for time in particular
it is 50/50 if it is a gain or loss.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: computer and wheel time

[Dan Espen]

Daniel Corbe <corbe@corbe.net> writes:

> Dan Espen <despen@verizon.net> writes:
>
>> Emanuel Berg <embe8573@student.uu.se> writes:
>>
>>> Marcin Borkowski <mbork@mbork.pl> writes:
>>>
>>>> Yeah, sure. That's a good idea in general, but it has
>>>> one drawback: there's only 24 hours per day. [...]
>>>>
>>>> Again: in general, yes. OTOH, there are so many
>>>> other enjoyable, interesting, and creative
>>>> activities out there, even if you use ready-made
>>>> solutions to /some/ of your problems... And writing
>>>> rather simple and boring Elisp code is not really
>>>> very high on my list. (Not that writing Elisp is
>>>> simple or boring in general: just that coding this
>>>> particular thing seems to me a lot like
>>>> reimplementing well-known things, and reimplementing
>>>> a "format"-like function, for instance, seems to be
>>>> not very enjoyable/interesting/creative...)
>>>
>>> In general, I'd say using a computer isn't a good idea
>>> if you are concerned with time. In particular, using
>>> Emacs and even more so, configuring/extending it will
>>> in effect disintegrate even the most sparse schedule!
>>
>> Actually, you spend a little time customizing then
>> real work goes faster, more accurately.  It's
>> a win win.
>>
>> The more you customize, the less time regular work
>> takes.
>>
>> Just try to keep the ratio under control.
>
> Eventually you begin to butt up against the law of diminishing returns.
> Spending half an hour on something that's going to save you 10 minutes
> every day is a net gain; however, you'll eventually run out of those
> types of problems to solve.
>
> Pretty soon you'll be spending half an hour on something that saves you
> 30 seconds here and there and that's likely to be a net loss.
>
> Then again, emacs really *can* do some pretty cool things.

Some of those things improve quality, it's not just a simple time
equation.

Also, many of the techniques people come up with get shared.
If the sharing group is large enough, even trivial improvements
pay off.

Then there is the downside of a totally static set of tools.
It's boring.

-- 
Dan Espen

Re: computer and wheel time

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> Some of those things improve quality, it's not just
> a simple time equation.
>
> Also, many of the techniques people come up with get
> shared. If the sharing group is large enough, even
> trivial improvements pay off.
>
> Then there is the downside of a totally static set
> of tools. It's boring.

Best thread ever!!!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 15:37, Tom Tromey <tom@tromey.com> wrote:

> Marcin> I'm going to start coding a major mode, a bit like dired or grep-mode or
> Marcin> org-agenda mode, in which the buffer will contain a bunch of lines, each
> Marcin> of them correspoding to some object (basically, I have a vector of these
> Marcin> "objects", and I want to display them in some way).
>
> People have already mentioned tabulated-list-mode.
>
> Another way to go is EWOC, also part of the Emacs core.
> EWOC is used at least by vc-dir but also I think some other modes.

Thanks a lot!  I looked into tabulated-list-mode and EWOC, and it seems
that EWOC is the way to go for me.

I have a few questions, though.  One thing I'd like to have is /sorting/
of the `things' in my ewoc based on different criteria.  Do I get it
correctly that I'll have to `ewoc-create' it from scratch?  DO I get it
correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
knowing that the old one will be GC'ed automatically?

Also, I'd like to color various entries in my ewoc, using different
faces.  Do I get it correctly that I should assign them faces right
after `insert'ing them in my pretty-printing function?

> I would suggest using whichever one fits your needs best.
>
> Tom

Thanks again,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Stefan Monnier]

> correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
> knowing that the old one will be GC'ed automatically?

You don't need to re-create the ewoc, but you can instead clear it
(e.g. with ewoc-filter) and then re-fill it.

> Also, I'd like to color various entries in my ewoc, using different
> faces.  Do I get it correctly that I should assign them faces right
> after `insert'ing them in my pretty-printing function?

Sounds fine, yes.  Sometimes it's more convenient to assign the face to
the strings before you insert them, but either way work fine.


        Stefan

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 03:50, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> correctly that I can just safely (setq my-ewoc (ewoc-create ...)),
>> knowing that the old one will be GC'ed automatically?
>
> You don't need to re-create the ewoc, but you can instead clear it
> (e.g. with ewoc-filter) and then re-fill it.

OK, that's almost the same, but seems cleaner.  And since I'm keeping
the ewoc in a global variable (there is no point in having more than one
instance in my use-case), it is also trivial.

>> Also, I'd like to color various entries in my ewoc, using different
>> faces.  Do I get it correctly that I should assign them faces right
>> after `insert'ing them in my pretty-printing function?
>
> Sounds fine, yes.  Sometimes it's more convenient to assign the face to
> the strings before you insert them, but either way work fine.

Thanks.  I ended up with squeezing a `propertize' between `insert' and
`format'.  This has a disadvantage (AFAIU) of creating a copy of the
string, but since my ewoc won't have more than, say, 100 elements,
I don't think it will slow things down a lot.

>         Stefan

Thanks a lot,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-08, at 04:17, Drew Adams <drew.adams@oracle.com> wrote:

>> the buffer will contain a bunch of lines, each of them
>> correspoding to some object (basically, I have a vector
>> of these "objects", and I want to display them in some way).
>
> Sounds like a candidate for `tabulated-list-mode'.  You can
> use that to print lines that are composed of one or more
> columns, and a header line that let you sort by any column
> (if you want).

Thanks for your tip, though after consideration I ended up using EWOC.

> [BTW, I would recommend against looking to things like Dired as
> examples for this kind of thing.  Dired is very complex and does
> lots of things in special ways.  And its code has evolved
> organically, so to speak. ;-)  It is not something simple like what
> you describe.  Look instead to things like buff-menu.el (which now
> uses t-l-mode) and `list-faces-display' and `list-colors-display'.

Fair enough.  I was mentioning Dired more to convey my needs than as
a suggestion that I'd like to mimick its implementation - it is far more
complex than what I need.

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

> Fair enough. I was mentioning Dired more to convey
> my needs than as a suggestion that I'd like to
> mimick its implementation - it is far more complex
> than what I need.

I think there are two schools how to do this.

The easiest way and the way I would do it is to just
write an iteration (or recursive) algorithm to
populate the window with data, which will also serve
as the UI.

Simply have a key (e.g., RET) execute an algorithm to
act on the data:

    (let ((data (thing-at-point ... )))
      (if ( ... data) (action data) ... ))

Last do polishing: font-lock keywords,
(speedified) cursor-movements, etc.

The more advanced way which is more schoolbookish and
ultimately more powerful (but it depends on the
purpose if such power is needed) is to have the UI
window-dressing separated from the logic - which you
instead put in text properties.

Then you can even have the UI format-stringed and have
the user curtain it in whatever way desired, but the
functionality will remain untouched.

-- 
underground experts united
http://user.it.uu.se/~embe8573

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> >> the buffer will contain a bunch of lines, each of them
> >> correspoding to some object (basically, I have a vector
> >> of these "objects", and I want to display them in some way).
> >
> > Sounds like a candidate for `tabulated-list-mode'.  You can
> > use that to print lines that are composed of one or more
> > columns, and a header line that let you sort by any column
> > (if you want).
> 
> Thanks for your tip, though after consideration I ended up using
> EWOC.

It might help others if you say why.  For example, what in your
problem context helped you decide that EWOC might be more useful
to it than `tabulated-list-mode'?

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Drew Adams <drew.adams@oracle.com> writes:

>> Thanks for your tip, though after consideration
>> I ended up using EWOC.
>
> It might help others if you say why. For example,
> what in your problem context helped you decide that
> EWOC might be more useful to it than
> `tabulated-list-mode'?

Otherwise it'll be like Napoleon before marching into
the Russian Empire: "You start it, then you see
what happens."

:)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 18:10, Drew Adams <drew.adams@oracle.com> wrote:

>> >> the buffer will contain a bunch of lines, each of them
>> >> correspoding to some object (basically, I have a vector
>> >> of these "objects", and I want to display them in some way).
>> >
>> > Sounds like a candidate for `tabulated-list-mode'.  You can
>> > use that to print lines that are composed of one or more
>> > columns, and a header line that let you sort by any column
>> > (if you want).
>> 
>> Thanks for your tip, though after consideration I ended up using
>> EWOC.
>
> It might help others if you say why.  For example, what in your
> problem context helped you decide that EWOC might be more useful
> to it than `tabulated-list-mode'?

Good point.

1. EWOC has built-in support for checking which entry the point is on.
I didn't find anything like that in tabulated-list-mode.

2. EWOC seems to be more flexible wrt the format of the entries.  In my
use case, each entry is a large-ish alist, converted from json by
json-read, and most of the entries in it should not show up at all.

OTOH, t-l-m has some things that EWOC doesn't:

1. Automatic sorting, though this is not that difficult to achieve in
EWOC, too.  (Also, what I need is a few more complicated sorting
algorithms - for instance, one of the columns is a timestamp, and I want
to be able to sort by time *or* by time of the day alone, disregarding
the date; I's also want to be able to do sorting based on more than one
column etc.)

2. A major mode to derive from - with EWOC, I'll probably end up
deriving my mode from special-mode.

So basically, while the differences are significant, both tools could do
the job - it just happens that EWOC has the parts I didn't want to code
myself already done.  As Emanuel points out, I could even do everything
myself from scratch.

BTW, be assured that when I finish my tool (or at least get to
a production-ready beta, which seems quite close), I'll write a blog
post (or a few) about it, and put the code on the net somewhere.  (I
won't write about it here too much, though, since it is a client for
a cloudy-ish service on the net which is not "free as in beer" and uses
software which is not "free as in FSF".  Moreover, the nature of the
service seems to almost *exclude* the possibility of a free version, at
least in the "as in beer" sense - "free as in FSF" might be
theoretically possible, though maybe unreasonable from business
standpoint - I see no much point in giving away server-side software
which is a basis for your rather niche business.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

Thanks for providing more info.

> 1. EWOC has built-in support for checking which entry the point is
> on. I didn't find anything like that in tabulated-list-mode.

Not sure what you mean, but that sounds like `tabulated-list-get-entry':

  Return the Tabulated List entry at POS. ... defaults to point.

or depending on what you mean, perhaps `tabulated-list-get-id':

  Return the entry ID of the Tabulated List entry at POS.
  ... defaults to point.

> 2. EWOC seems to be more flexible wrt the format of the entries.  In
> my use case, each entry is a large-ish alist, converted from json by
> json-read, and most of the entries in it should not show up at all.

So you want to show only some of each alist entry.

  `tabulated-list-print' calls the printer function specified by
  `tabulated-list-printer', once for each entry.  The default
  printer is `tabulated-list-print-entry', but a mode that keeps
  data in an ewoc may instead specify a printer function (e.g., one
  that calls `ewoc-enter-last'), with `tabulated-list-print-entry'
  as the ewoc pretty-printer.

and `tabulated-list-entries':

  If a list, each element has the form (ID [DESC1 ... DESCN])
  
or it can be a function that returns such a list.

In your case, one of the DESC would presumably be your alist value,
formatted to show only some of it.

I know very little about EWOC, but so far I don't really see what
more it offers here.  (Not that I need to.  The info you provide is
anyway helpful.) 

> I's also want to be able to do sorting based on more than one
> column

Same here.  That would be a useful addition to `tabulated-list-mode'.

> So basically, while the differences are significant, both tools
> could do the job - it just happens that EWOC has the parts I didn't
> want to code myself already done.

Understood (though it's not clear to me what those parts are).

> BTW, be assured that when I finish my tool (or at least get to
> a production-ready beta, which seems quite close), I'll write a blog
> post (or a few) about it, and put the code on the net somewhere.

Thx. 

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 21:50, Drew Adams <drew.adams@oracle.com> wrote:

> Thanks for providing more info.
>
>> 1. EWOC has built-in support for checking which entry the point is
>> on. I didn't find anything like that in tabulated-list-mode.
>
> Not sure what you mean, but that sounds like `tabulated-list-get-entry':
>
>   Return the Tabulated List entry at POS. ... defaults to point.
>
> or depending on what you mean, perhaps `tabulated-list-get-id':
>
>   Return the entry ID of the Tabulated List entry at POS.
>   ... defaults to point.

Cool.  Neither is mentioned in the Info manual, though...

>> 2. EWOC seems to be more flexible wrt the format of the entries.  In
>> my use case, each entry is a large-ish alist, converted from json by
>> json-read, and most of the entries in it should not show up at all.
>
> So you want to show only some of each alist entry.
>
>   `tabulated-list-print' calls the printer function specified by
>   `tabulated-list-printer', once for each entry.  The default
>   printer is `tabulated-list-print-entry', but a mode that keeps
>   data in an ewoc may instead specify a printer function (e.g., one
>   that calls `ewoc-enter-last'), with `tabulated-list-print-entry'
>   as the ewoc pretty-printer.
>
> and `tabulated-list-entries':
>
>   If a list, each element has the form (ID [DESC1 ... DESCN])
>   
> or it can be a function that returns such a list.
>
> In your case, one of the DESC would presumably be your alist value,
> formatted to show only some of it.
>
> I know very little about EWOC, but so far I don't really see what
> more it offers here.  (Not that I need to.  The info you provide is
> anyway helpful.) 

So it seems that the main advantage of EWOC is better (i.e., more
comprehensive) manual...

>> I's also want to be able to do sorting based on more than one
>> column
>
> Same here.  That would be a useful addition to `tabulated-list-mode'.
>
>> So basically, while the differences are significant, both tools
>> could do the job - it just happens that EWOC has the parts I didn't
>> want to code myself already done.
>
> Understood (though it's not clear to me what those parts are).

Maily the get-item-at-point, which t-l-m seems to have, too...  Also,
the sorting stuff, though this is not really relevant: I presume that
with t-l-m, I could do sorting "manually", i.e., on the underlying data
structure.

All in all, it seems that (apart from the manual) EWOC has only one
advantage for me: I already have some working code using it...

>> BTW, be assured that when I finish my tool (or at least get to
>> a production-ready beta, which seems quite close), I'll write a blog
>> post (or a few) about it, and put the code on the net somewhere.
>
> Thx. 

You're welcome, though it will take some time (I'm going for a vacation
in a few days).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

RE: Seeking advice on writing a "line-based" major mode

[Drew Adams]

> > `tabulated-list-get-entry':
> >   Return the Tabulated List entry at POS...
> > `tabulated-list-get-id':
> >   Return the entry ID of the Tabulated List entry at POS...
> 
> Cool.  Neither is mentioned in the Info manual, though...

If you think it is important/useful, consider filing a doc bug:
`M-x report-emacs-bug'.

> So it seems that the main advantage of EWOC is better (i.e., more
> comprehensive) manual...

If you think so: `M-x report-emacs-bug'.

> >> EWOC has the parts I didn't want to code myself already done.
> > Understood (though it's not clear to me what those parts are).
> 
> Maily the get-item-at-point, which t-l-m seems to have, too...
> Also, the sorting stuff, though this is not really relevant: I presume
> that with t-l-m, I could do sorting "manually", i.e., on the underlying
> data structure.

Yes, you can sort the data any way you like.  You can associate different
sorts with different columns, so that when you hit return with point in a
given column a given sort predicate is used.

The SORT value specified in `tabulated-list-format' for each column: 

 - SORT specifies how to sort entries by this column.
   If nil, this column cannot be used for sorting.
   If t, sort by comparing the string value printed in the column.
   Otherwise, it should be a predicate function suitable for
   `sort', accepting arguments with the same form as the elements
   of `tabulated-list-entries'.

What is passed to the sort function to compare are two rows of the
table (not as displayed, but the underlying data), i.e., "elements
of `tabulated-list-entries'".

> All in all, it seems that (apart from the manual) EWOC has only one
> advantage for me: I already have some working code using it...

;-)  It may have other advantages too; dunno.

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> I think there are two schools how to do this.
>
> The easiest way and the way I would do it is to just
> write an iteration (or recursive) algorithm to
> populate the window with data, which will also serve
> as the UI.
>
> Simply have a key (e.g., RET) execute an algorithm to
> act on the data:
>
>     (let ((data (thing-at-point ... ))) (if ( ...
> data) (action data) ... ))

Here is an example of this method - or check out the
file here:

    http://user.it.uu.se/~embe8573/line-file-table.el

See that last comment block for how to invoke AND an
interesting thing with point position that differs in
byte-compiled vs. normal mode.

(defun find-file-at-line (&optional other-window)
  (interactive "P")
  (let ((possible-filename (thing-at-point 'filename))
        (find-f (if other-window 'find-file-other-window 'find-file)) )
    (if (and possible-filename (file-exists-p possible-filename))
          (apply find-f `(,possible-filename))
      (progn
        (forward-char 1)
        (find-file-at-line) ))))

(defvar *files* '("~/.emacs" "~/.gnus" "~/.zshrc" "~/.zshenv"))

(defun make-table ()
    (insert ";; Either press M-RET or M-r to visit a file.\n"
            ";; If a file doesn't exist, the next one is tried.\n;;\n" )
    (save-excursion ; [1]
      (dolist (f *files*)
        (insert (format ";; %s\n" f)) )))

(local-set-key "\M-\r" 'find-file-at-line) ; M-RET
(local-set-key "\M-r"  'find-file-at-line) ; M-r

(make-table)

;; [1] for whatever reason (?) this isn't applied with
;;
;;         emacs -Q -l ~/line-file-table.el
;;
;;     but if compiled first
;;
;;         emacs --batch -f batch-byte-compile ~/line-file-table.el;
;;         emacs -Q -l ~/line-file-table.elc
;;
;;     then it works.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Emanuel Berg]

Here is a hybrid: buttons, but data as the button
labels - that's clever, ey?

(defun find-file-button-f (button)
  (find-file (button-label button)) )

(define-button-type 'find-file-button
  'action 'find-file-button-f
  'follow-link t)

(defvar *files* '("~/.emacs" "~/.gnus" "~/.zshrc" "~/.zshenv"))

(insert "Hit RET on these buttons to visit the file.\n"
        "If there isn't such a file, open an empty buffer with that name.\n\n")

(save-excursion ; doesn't work if not compiled (see last comment)
  (dolist (f *files*)
    (insert-text-button f :type 'find-file-button)
    (insert "\n") ))

;; execute:
;;
;;    emacs -Q -l button.el
;;
;; or:
;;
;;    emacs --batch -f batch-byte-compile button.el
;;    emacs -Q -l button.elc

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Seeking advice on writing a "line-based" major mode

[Marcin Borkowski]

On 2015-06-18, at 21:50, Drew Adams <drew.adams@oracle.com> wrote:

>> So basically, while the differences are significant, both tools
>> could do the job - it just happens that EWOC has the parts I didn't
>> want to code myself already done.
>
> Understood (though it's not clear to me what those parts are).
>
>> BTW, be assured that when I finish my tool (or at least get to
>> a production-ready beta, which seems quite close), I'll write a blog
>> post (or a few) about it, and put the code on the net somewhere.
>
> Thx. 

OK, so the blog post is online:
http://mbork.pl/2015-07-18_TLM_vs_EWOC%2c_or_there_and_back_again
(There are some problems with the styling on my site, but I don't have
time to fix that now, sorry.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: Seeking advice on writing a "line-based" major mode

[Robert Thorpe]

Marcin Borkowski <mbork@mbork.pl> writes:
...
>
> OK, so the blog post is online:
> http://mbork.pl/2015-07-18_TLM_vs_EWOC%2c_or_there_and_back_again
> (There are some problems with the styling on my site, but I don't have
> time to fix that now, sorry.)

That's useful to me.  I'm planning to write a mode using one of those
two libraries in a few months time.

Thanks,
Robert Thorpe