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

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

[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

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

[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: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)