Menu
▾
▴
phpwiki-talk
|
From: Joel U. <uck...@no...> - 2001-06-26 19:16:59
|
Quoth Reini Urban: > Steve Wainstead schrieb: > > I've read through the PEAR coding standards and they look good. I'd like > > all the project code to use them. You can take a look at > > http://www.php.net/manual/en/pear.standards.php. > > most of it is fine for me, I just don't like the "one true brace" function > declaractions follow convention: > > function fooFunction($arg1, $arg2 = '') > { > if (condition) { > statement; > } > return $val; > } > > I do: > function fooFunction ($arg1, $arg2 = '') { Me too. I think that's in the spirit of old-skool K&R C. Of course, this sort of thing is how epic flamewars get started. Heh. :) -- J. |
|
From: Jeff D. <da...@da...> - 2001-06-26 20:09:48
|
>... we have a lot of dangling if statements of the form:
>
>if (foo)
> statement;
>
>which will have to be excorcised...
I vote that we don't worry about these too much. The only thing I can
find in the PEAR coding standards which addresses this is:
You are strongly encouraged to always use curly braces even in
situations where they are technically optional. Having them
increases readability and decreases the likelihood of logic
errors being introduced when new lines are added.
("Strongly encouraged" != "required".)
|
|
From: Steve W. <sw...@pa...> - 2001-06-26 19:58:53
|
On Tue, 26 Jun 2001, Joel Uckelman wrote:
> Me too. I think that's in the spirit of old-skool K&R C. Of course, this sort of thing is how epic flamewars get started. Heh. :)
They are as amusing as tiresome:
spaces vs. tabs
Emacs vs. vi
Linux vs. *bsd
Netscape vs. IE
am I missing any? ;-)
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
|
|
From: Reini U. <ru...@x-...> - 2001-06-26 20:24:23
|
Steve Wainstead schrieb: > On Tue, 26 Jun 2001, Joel Uckelman wrote: > > Me too. I think that's in the spirit of old-skool K&R C. Of course, this sort of thing is how epic flamewars get started. Heh. :) > > They are as amusing as tiresome: > spaces vs. tabs > Emacs vs. vi > Linux vs. *bsd > Netscape vs. IE > > am I missing any? ;-) Emacs vs XEmacs and Scheme vs Common Lisp are the worst in my communities. perl vs python, GPL vs BSD-style and GPL vs Artistic also leeds to amusing flamewars. relatively new is postgreSQL vs mysql. local popularity here got debian vs SUSE and KDE vs Gnome. it's always good to have options :) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: J C L. <cl...@ka...> - 2001-06-27 05:37:39
|
On Tue, 26 Jun 2001 12:42:40 -0400 (EDT) Steve Wainstead <sw...@pa...> wrote: > I've read through the PEAR coding standards and they look > good. I'd like all the project code to use them. You can take a > look at http://www.php.net/manual/en/pear.standards.php. So drop an Emacs mode comment at the top of all the files so your editor Does The Right Thing and then forget about it. Yeesh. <<Written as one who disagrees rather strenuously with the PEAR coding standards, but doesn't really care about it either -- that's what M-x indent region is for>> -- J C Lawrence cl...@ka... ---------(*) http://www.kanga.nu/~claw/ I never claimed to be human. |
|
From: J C L. <cl...@ka...> - 2001-06-27 05:40:09
|
On Tue, 26 Jun 2001 15:58:51 -0400 (EDT) Steve Wainstead <sw...@pa...> wrote: > They are as amusing as tiresome: > spaces vs. tabs Emacs vs. vi Linux vs. *bsd Netscape vs. IE > am I missing any? ;-) bash vs tcsh, perl cs python, (La)TeX vs <insert WYSIWYG WordProcessor>, GNOME vs KDE (both are equally useless), top down versus bottom up, OO vs procedural, Free Software vs Open Source.... And it goes on from there. -- J C Lawrence cl...@ka... ---------(*) http://www.kanga.nu/~claw/ I never claimed to be human. |
|
From: Steve W. <sw...@pa...> - 2001-06-27 06:23:32
|
On Tue, 26 Jun 2001, J C Lawrence wrote:
> On Tue, 26 Jun 2001 15:58:51 -0400 (EDT)
> Steve Wainstead <sw...@pa...> wrote:
>
> > am I missing any? ;-)
>
> bash vs tcsh
wow, can't believe I overlooked that one...
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
|
|
From: Jeff D. <da...@da...> - 2001-09-08 21:24:16
|
Just to clarify, the php-mode tab-width setting does not affect how far blocks of code are indented (c-basic-offset controls that, and I'm not suggesting changing that). The tab-width setting (in combination with indent-tabs-mode (see below)) just controls how emacs achieves that indentation. If tab-width is set to 4 (as PEAR dictates), then emacs assumes that a tab character in the text moves to the next multiple of 4 columns. The problem with this, is that most text file viewers assume that a tab moves to the next multiple of 8 columns, so code which looks fine when viewed with a tab-width setting of 4 can look severely mangled when viewed with other programs. > I actually rangled over this for some time with some programmer friends. I > think I posted a link to this list that was something written by jwz about > why you should not use tabs at all. It was pretty sound. Yes, I agree. Setting indent-tabs-mode to 'nil forces php-mode not to use tabs at all, and just indent with spaces. This is good. The problem is that unless great care is taken to eliminate all tabs in the source code, some tabs will remain. When indentation is achieved with a mixture of spaces and tabs, then things get particularly badly munged when viewed by a viewer with a different idea of what the tab-width is. I think the intention of the PEAR standards is that indentation be achieved using only tabs. This allows individuals to adjust the displayed indentation just by changing the tab-width. The problem is that even when tab-width == c-basic-offset, emacs does not really guarantee that all indentation is achieved using tabs rather than spaces. If you use, e.g. 'less' to view the PEAR source code (at least the version I've got) the problem will be immediately obvious. In general, most blocks are indented 8 columns (since tabs were used) --- that's ugly and hard to read as you point out, but at least the indentation still properly shows the block structure. However some lines in the PEAR code are indented with spaces. Those lines only shift blocks over four columns. The result is that nothing lines up with anything. |
|
From: Steve W. <sw...@pa...> - 2001-09-16 21:09:11
|
On Sat, 8 Sep 2001, Jeff Dairiki wrote:
> I think the intention of the PEAR standards is that indentation be
> achieved using only tabs. This allows individuals to adjust
> the displayed indentation just by changing the tab-width.
> The problem is that even when tab-width == c-basic-offset, emacs
> does not really guarantee that all indentation is achieved using
> tabs rather than spaces.
Hmm. The page states: "Use an indent of 4 spaces, with no tabs. If you use
Emacs to edit PEAR code, you should set indent-tabs-mode to nil." So the
intention is to do away with tabs altogether, I suppose. If you need to
put tabs in the code then \t is the way to go. However I'm in a flexible
mood today...
I'm willing to concede this point for the greater good of the project: if
everyone is happy with tabs, and adjusting your editor accordingly, we'll
go with tabs and I'll have to fix my .emacs file.
cheers
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Jeff D. <da...@da...> - 2001-09-17 16:51:20
|
On Sep 16, 2001, Steve Wainstead said: > > Hmm. The page states: "Use an indent of 4 spaces, with no tabs. If you use > Emacs to edit PEAR code, you should set indent-tabs-mode to nil." So the > intention is to do away with tabs altogether, I suppose. If you need to > put tabs in the code then \t is the way to go. However I'm in a flexible > mood today... > > I'm willing to concede this point for the greater good of the project: if > everyone is happy with tabs, and adjusting your editor accordingly, we'll > go with tabs and I'll have to fix my .emacs file. To restate and (hopefully) clarify once again: My only beef is with tab-width=4. Setting indent-tabs-mode to nil is, I think, a fine way to go. But even with that setting, it's almost inevitable that some real tabs will make their way into the source code. (The PEAR source code demonstrates this quite well.) I just think those tabs that do make it into the source code should always be rendered as eight-space tabs, rather than funky four-space tabs. Here's what I'm proposing we use: // Local Variables: // mode: php // tab-width: 8 // c-basic-offset: 4 // c-hanging-comment-ender-p: nil // indent-tabs-mode: nil // End: If we include the above cruft in our source code, then you (probably) don't even need to fix your .emacs. Jeff |
|
From: Steve W. <sw...@pa...> - 2001-09-17 17:22:34
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote:
> To restate and (hopefully) clarify once again:
>
> My only beef is with tab-width=4. Setting indent-tabs-mode to nil is,
> I think, a fine way to go. But even with that setting, it's almost
> inevitable that some real tabs will make their way into the source code.
> (The PEAR source code demonstrates this quite well.) I just think those
> tabs that do make it into the source code should always be rendered as
> eight-space tabs, rather than funky four-space tabs.
Aha! OK, now I see what you mean. I thought you wanted to indent code with
tabs, which I still have serious misgivings about. tab-width=8 is
preferable, indeed, if we are using indent-tabs-mode=nil.
>
> Here's what I'm proposing we use:
>
> // Local Variables:
> // mode: php
> // tab-width: 8
> // c-basic-offset: 4
> // c-hanging-comment-ender-p: nil
> // indent-tabs-mode: nil
> // End:
>
> If we include the above cruft in our source code, then you (probably)
> don't even need to fix your .emacs.
Perfect. We are in agreement and everyone is happy. :-)
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Reini U. <ru...@x-...> - 2001-09-18 11:16:38
|
Jeff Dairiki schrieb:
> Here's what I'm proposing we use:
> // Local Variables:
> // mode: php
> // tab-width: 8
> // c-basic-offset: 4
> // c-hanging-comment-ender-p: nil
> // indent-tabs-mode: nil
> // End:
I don't know why now, but I have added "ellemtel" somewhen:
phpwiki-footer:
// For emacs users
// Local Variables:
// mode: php
// tab-width: 8
// c-basic-offset: 4
// c-hanging-comment-ender-p: nil
// indent-tabs-mode: nil
// c-file-style: "ellemtel"
// End:
?>
W:\XEmacs\xemacs-packages\lisp\cc-mode\cc-styles.el defines this:
("ellemtel"
(c-basic-offset . 3)
(c-comment-only-line-offset . 0)
(c-hanging-braces-alist . ((substatement-open before after)))
(c-offsets-alist . ((topmost-intro . 0)
(topmost-intro-cont . 0)
(substatement . +)
(substatement-open . 0)
(case-label . +)
(access-label . -)
(inclass . ++)
(inline-open . 0)
))
)
We could add a "PEAR" style table to cc-styles.el somewhen later.
But local overrides are always better.
("PEAR"
(tab-width . 8)
(indent-tabs-mode . nil)
(c-basic-offset . 4)
(c-hanging-comment-ender-p . 0)
(c-comment-only-line-offset . 0)
(c-hanging-braces-alist . ((substatement-open before after)))
(c-offsets-alist . ((topmost-intro . 0)
(topmost-intro-cont . 0)
(substatement . +)
(substatement-open . 0)
(case-label . +)
(access-label . -)
(inclass . ++)
(inline-open . 0)
))
)
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
|
|
From: Jeff D. <da...@da...> - 2001-09-18 15:08:43
|
On Sep 18, 2001, Reini Urban said: > > I don't know why now, but I have added "ellemtel" somewhen: > > phpwiki-footer: > // For emacs users > // Local Variables: > // mode: php > // tab-width: 8 > // c-basic-offset: 4 > // c-hanging-comment-ender-p: nil > // indent-tabs-mode: nil > // c-file-style: "ellemtel" > // End: > ?> That's my fault, probably. Ellemtel's (whoever he was) style matches the _old_ PhpWiki style best, but does not work so well for the new, PEAR indentation style. 'Gnu' (which is the default for php-mode) is the style I've been using as of late. But, note also that you can't use 'c-file-style: gnu' in the file local variable hooks section. If you do, (c-set-style 'gnu') which gets called after the other file local variables get set up, resets c-basic-offset (and others) to the defaults for the style. (The default is c-basic-offset=2 for the gnu style.) Jeff |
|
From: Jeff D. <da...@da...> - 2001-09-17 16:40:18
|
Steve Wainstead wrote: > Wikis are commonly used by development folks as a sort of whiteboard/on > the fly documentation system. This means any common comment tokens like > > # > ; > /* */ > // > -- > <!-- --> > > are probably not a good idea, > An interesting point! On the other hand, introducing yet another quasi-random piece of markup syntax is not necessarily the greatest idea either. You can't really just paste code into PhpWiki even now. If you ensure each line is indented, then it works okay, but you still get sporadic WikiLinks... (Note that if one requires comments to start in column zero, then conflicts with cut-and-pasted code are pretty much eliminated.) UseMod has support for <pre></pre> tags which really do disable all markup, and are therefore quite useful for posting code. I wouldn't mind seeing something like this incorporated into PhpWiki. |
|
From: Jeff D. <da...@da...> - 2001-09-17 18:09:41
|
> Hmm. As a serialized string? You might want to expand on this. I think the
> idea of them having a home page on the wiki is a natural.
The new database API allows (more-or-less) for arbitrary key/value pairs
to be attached to pages as meta-data. This data is accessed via the
WikiDB_Page::get() and WikiDB_Page::set() methods. (And yes, the
implementation involves storing a serialized hash.) So this is a real
quick-and-dirty place to store user meta-data if we establish a
correspondence
between users and pages.
I'm thinking that pages which serve as user homepages would have
additional meta-data something like:
is_homepage: 1
password: md5:12ef...
user_email: <da...@da...>
This is data that would otherwise be stored in a separate user database
(e.g. /etc/passwd).
> Like I said, it just seems like a natural. I would use SteveWainstead or
> just 'wainstead' as an ID and would want my name to hyperlink to a page
> about me.
Yes, my main point of concern/confusion right now concerns the
following scenario:
You attempt to register (via some automatic scheme, like the one
you've outlined below) as a new user with the userid SteveWainstead.
The page SteveWainstead already exists.
What to do? Should you be allowed to take over the existing page
as your homepage? (What if you were trying to register under the
userid of FrontPage or CategoryNextWiki?)
(I guess this scenario addresses a more generic issue than that of just
user registration --- more that of page ownership. Who should be
allowed
to own/lock which (pre-existing) pages?)
> What I would really like to see added is user registration, where users
> must have a valid email address to register with the Wiki. This would be
> useful for a public wiki that only allows members to edit pages, and
> guests can only browse. In corporate intranets this would be essential.
Yes. This is what has been in the back of mind (I think you planted
the seed there) for awhile now. I keep hoping to find some
pre-written library which handles the details, but I don't think
were going to find one...
|
|
From: Steve W. <sw...@pa...> - 2001-09-17 19:17:43
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote:
> > Hmm. As a serialized string? You might want to expand on this. I think the
> > idea of them having a home page on the wiki is a natural.
>
> The new database API allows (more-or-less) for arbitrary key/value pairs
> to be attached to pages as meta-data. This data is accessed via the
> WikiDB_Page::get() and WikiDB_Page::set() methods. (And yes, the
> implementation involves storing a serialized hash.) So this is a real
> quick-and-dirty place to store user meta-data if we establish a
> correspondence
> between users and pages.
OK... my experience has been, whenever you denormalize the database
design, you wind up wanting to get at the info that's no longer atomic.
In this case it might be better to just go ahead and create a user table,
since we will have one anyhow, no matter what. User auth is coming and
storing users and pages in the same table will cause problems.
> Yes, my main point of concern/confusion right now concerns the
> following scenario:
>
> You attempt to register (via some automatic scheme, like the one
> you've outlined below) as a new user with the userid SteveWainstead.
>
> The page SteveWainstead already exists.
>
> What to do? Should you be allowed to take over the existing page
> as your homepage? (What if you were trying to register under the
> userid of FrontPage or CategoryNextWiki?)
>
> (I guess this scenario addresses a more generic issue than that of just
> user registration --- more that of page ownership. Who should be
> allowed
> to own/lock which (pre-existing) pages?)
For now we might just let the username link to a page of the same name,
and if they want to be called HomePage, well, what can one do.
> Yes. This is what has been in the back of mind (I think you planted
> the seed there) for awhile now. I keep hoping to find some
> pre-written library which handles the details, but I don't think
> were going to find one...
I haven't looked... there must be something like this. On a similar note,
how hard would it be to make the diff engine a module people could reuse?
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Jeff D. <da...@da...> - 2001-09-18 16:18:46
|
On Sep 17, 2001, Steve Wainstead said:
>
> OK... my experience has been, whenever you denormalize the database
> design, you wind up wanting to get at the info that's no longer atomic.
Er... Could you say that again, in English?
> In this case it might be better to just go ahead and create a user table,
> since we will have one anyhow, no matter what. User auth is coming and
> storing users and pages in the same table will cause problems.
That is the kind of answer I was looking for, but how, exactly, is it
going to cause problems?
To clarify, again, my proposal:
In the new API, arbitrary key/value meta-data can be attached to any
page.
The way you (the PHP programmer) does this is via an interface like:
$page = $dbi->getPage('JeffDairiki');
$page->set('is_homepage', 1);
$page->set('password', 'gobbledygook');
....
if ($page->get('is_homepage')) {
$passwd = $page->get('password');
...
}
(Right now, the only page meta-data being used is 'locked' and 'hits'.)
This data is not visible (or editable) to the wiki-user without
providing
some explicit mechanism for this. (I.e. the MostPopular plugin displays
the value of 'hits'.) (The DebugInfo plugin currently displays all of
the page meta-data --- but obviously that would be fixed if sensitive
information like passwords were stored as page meta-data.)
My thinking is that if everyone is going to have a WikiHomepage, then
storing their user information as part of the meta-data for their
homepage
is a fine idea.
I'm also, of course, trying to avoid implementing yet another database
interface (with mechanisms for backing up and restoring, etc...)
How much user information do we envision storing, anyhow?
E-mail address
Password
Full name, probably
Page change notification prefs: these might be better stored as
meta-data attached to the pages for which notification is desired?
Or one could also think up other schemes: user gets change
notifications for all pages linked from their homepage...
> For now we might just let the username link to a page of the same name,
> and if they want to be called HomePage, well, what can one do.
But if it really is their homepage, they ought to be allowed to lock
it...
> I haven't looked... there must be something like this. On a similar note,
> how hard would it be to make the diff engine a module people could reuse?
Easy. This was my original intent. I don't know who it was (Arno
maybe?) who
added the PhpWiki-specific code on the end of my diff source file ---
actually,
maybe it _was_ me, I can't remember --- in any case, I always
envisioned that nothing but class definitions be in 'libdiff.php' and
the
PhpWiki invocation of the classes somewhere else.
I suppose my diff code could still use a little cleaning up --- and
could
certainly use docs --- but it's basically ready to go.
On the subject: I want to add the ability to generate word-level diffs,
a la emacs' ediff mode. This would be particularly useful for wikis,
where a "line" can be a whole paragraph --- if only one word has been
changed, often it's very hard to spot. I think this is a fairly
straightforward enhancement: compute the diff normally (by lines), then
foreach block of changed lines, split the blocks into words and compute
a diff by words.
|
|
From: Steve W. <sw...@pa...> - 2001-09-18 16:44:00
|
On Tue, 18 Sep 2001, Jeff Dairiki wrote:
> > In this case it might be better to just go ahead and create a user table,
> > since we will have one anyhow, no matter what. User auth is coming and
> > storing users and pages in the same table will cause problems.
>
> That is the kind of answer I was looking for, but how, exactly, is it
> going to cause problems?
Oh, just that I imagine later on we will want (or admins will want) more
flexible, accessible access to user info. If you want to generate a list
of all users who accessed the wiki in the last ten days, how would you
write a SQL query to do that if all the user info is in page metadata?
Just an example.
> To clarify, again, my proposal:
> In the new API, arbitrary key/value meta-data can be attached to any
> page.
>
> The way you (the PHP programmer) does this is via an interface like:
> $page = $dbi->getPage('JeffDairiki');
> $page->set('is_homepage', 1);
> $page->set('password', 'gobbledygook');
>
> ....
> if ($page->get('is_homepage')) {
> $passwd = $page->get('password');
> ...
> }
>
I like this idea... having hashes for whatever one might want is always
useful!
> I'm also, of course, trying to avoid implementing yet another database
> interface (with mechanisms for backing up and restoring, etc...)
quite understandable...
> I suppose my diff code could still use a little cleaning up --- and
> could
> certainly use docs --- but it's basically ready to go.
Cool.
> On the subject: I want to add the ability to generate word-level diffs,
> a la emacs' ediff mode. This would be particularly useful for wikis,
> where a "line" can be a whole paragraph --- if only one word has been
> changed, often it's very hard to spot. I think this is a fairly
> straightforward enhancement: compute the diff normally (by lines), then
> foreach block of changed lines, split the blocks into words and compute
> a diff by words.
And I'd still like to redo the diff output to look like sdiff, or what you
get from cvsweb.cgi... very readable...
~swain
---
http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
-- Frank Zappa
http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC
|
|
From: Adam S. <ad...@pe...> - 2001-09-18 18:28:25
|
> (Right now, the only page meta-data being used is 'locked' and > 'hits'.) This data is not visible (or editable) to the wiki-user > without providing some explicit mechanism for this. (I.e. the > MostPopular plugin displays the value of 'hits'.) (The DebugInfo > plugin currently displays all of the page meta-data --- but obviously > that would be fixed if sensitive information like passwords were > stored as page meta-data.) or maybe make debug only available to the listed wiki admins? also passwords should not be stored in plain text. what about a worse is better solution of just storing the crypted password as plainly visible metadata? it can be brute forced but it's simple and if people choose good passwords (ha!) it should be "good enough". > My thinking is that if everyone is going to have a WikiHomepage, then > storing their user information as part of the meta-data for their > homepage is a fine idea. i really like this idea, it feels like the "wiki way" to me. > How much user information do we envision storing, anyhow? > E-mail address > Password > Full name, probably maybe later, groups that you belong to (admin, editor etc) > Page change notification prefs: these might be better stored as > meta-data attached to the pages for which notification is desired? > Or one could also think up other schemes: user gets change > notifications for all pages linked from their homepage... i was just thinking about this. i think it makes more sense to have it stored in the page name, other wise every page update means that the entire user database has to be searched everytime a page is changed to see who should get emailed. however this means that unsubing from a wiki could be a pita if you have 10's of pages that you're sub'd to. some form of search tool or "unsub all" functionality would be very useful. > > For now we might just let the username link to a page of the same name, > > and if they want to be called HomePage, well, what can one do. > > But if it really is their homepage, they ought to be allowed to lock > it... lets not look at automated ways of stopping this. hopefully this will be a small enough problem that the admin can deal with it manually. most of the pages which would cause problems if someone chose them for a name (HomePage, FrontPage, RecentChanges, CategoryCategory etc) should exist by default in the basic wiki. > On the subject: I want to add the ability to generate word-level > diffs, a la emacs' ediff mode. This would be particularly useful for > wikis, where a "line" can be a whole paragraph --- if only one word > has been changed, often it's very hard to spot. I think this is a > fairly straightforward enhancement: compute the diff normally (by > lines), then foreach block of changed lines, split the blocks into > words and compute a diff by words. that would be great, can we have side by side diffs as well? adam. |
|
From: Reini U. <ru...@x-...> - 2001-09-18 16:39:29
|
Jeff Dairiki schrieb: > On the subject: I want to add the ability to generate word-level diffs, > a la emacs' ediff mode. This would be particularly useful for wikis, > where a "line" can be a whole paragraph --- if only one word has been > changed, often it's very hard to spot. I think this is a fairly > straightforward enhancement: compute the diff normally (by lines), then > foreach block of changed lines, split the blocks into words and compute > a diff by words. Yes, this is by far better. It is even the best diff I know of. yellow for lines and blue for words. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X